Re: NFS-mounting crontabs
martin f krafft said on Sat, Nov 06, 2004 at 12:30:06PM +0100:
also sprach Mark Ferlatte [EMAIL PROTECTED] [2004.11.06.0123 +0100]:
Do you really want your user's crontabs to run on every host in your
cluster?
They are mounted from master:/srv/var/spool/crontabs/${HOSTNAME}, so
they are per host.
Okay. I guess my next question is: why do you want your user crontabs NFS
mounted from your clients? Since they are local configs, why not just let them
be local? If you feel that you have to backup your crontabs for each host,
have a cronjob on each host that does a cp -a /var/spool/cron
/mount/master/srv/var/spool/crontabs/$HOSTNAME, or whatever.
This actually closes a security hole; if you are NFS mounting your crons, then
all I have to do is spoof your client's NFS mount (or response) to get cron to
run any command I want as any user on that system.
One idea I had last night is a crontab wrapper, along with
a root_squash NFS export. A cron job copies the files from there to
/var/spool/cron/crontabs as you describe. But when the user calls
crontab, what happens is that the file is first explicitly copied
from the NFS mount, then crontab(1) is invoked, and upon exit, the
user crontab is saved back to the NFS. I think this would work fine,
don't you think?
Sure, if you want to go that way, a wrapper around crontab is fine.
M
pgpysO2lQrBaF.pgp
Description: PGP signature
Re: exim or postfix
Rodney Richison said on Sat, Nov 06, 2004 at 09:19:40PM -0600: Are most of you using exim or postfix? Just curious. I've never tried exim. Don't know about most; I use Postfix. I don't think exim is a bad choice, though; I just liked Postfix better, and it performs well enough to meet my needs. M pgpwRaGgrw1KM.pgp Description: PGP signature
Re: Limiting User Commands
On Fri, Nov 05, 2004 at 07:53:33PM +0200, [EMAIL PROTECTED] wrote: In regards to the latter method, would it be possible for me to change the group ownership of the commands I don't want users to have access to and revoke execute permission from that group? Yes, you can make something like that: addgroup(access), then change groupname of commands that you want with that group (access), remember to remove execute/search by others from commands that are with group(access), also don't forget to add group(access) to every user that you want to have access to this commands. The only problem with this approach would be that you'd revoke it from system accounts too, not just your users. It might break in unexpected places. It seems to me that this should be possible with SELinux. What you need would be a role for your users where they are only able to run the commands you want them to run, whereas system accounts would remain unblocked. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: exim or postfix
On Sat, Nov 06, 2004 at 09:19:40PM -0600, Rodney Richison wrote: Are most of you using exim or postfix? Just curious. I've never tried exim. exim4 and postfix, depending on the machine, and who origionally set it up. New machines are getting exim4 because it is far more flexible and powerful that postfix (in my experience). Cheers, -- Brett Parker web: http://www.sommitrealweird.co.uk/ email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: exim or postfix
also sprach Mark Ferlatte [EMAIL PROTECTED] [2004.11.07.1013 +0100]: Don't know about most; I use Postfix. I don't think exim is a bad choice, though; I just liked Postfix better, and it performs well enough to meet my needs. Well said. also sprach Brett Parker [EMAIL PROTECTED] [2004.11.07.1226 +0100]: exim4 and postfix, depending on the machine, and who origionally set it up. New machines are getting exim4 because it is far more flexible and powerful that postfix (in my experience). Well, my last tests have shown postfix to be more performant by about a factor of 1.6. In addition, there is the single setuid binary thing about exim. You are right that exim has a lot more features than postfix. However, are they needed? To me, exim tries to be more than an MTA, which is why I surely prefer postfix. I can't wait until I have time to try/use/improve Md's policy framework. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: NFS-mounting crontabs
also sprach Mark Ferlatte [EMAIL PROTECTED] [2004.11.07.1012 +0100]: Okay. I guess my next question is: why do you want your user crontabs NFS mounted from your clients? The cluster nodes are frequently reinstalled, so the crontabs need to be installed automatically. This actually closes a security hole; if you are NFS mounting your crons, then all I have to do is spoof your client's NFS mount (or response) to get cron to run any command I want as any user on that system. Hey, it's NFS. It's inherently insecure. Until I switch it all to IPsec, the cluster is open to everyone with physical access. One idea I had last night is a crontab wrapper, along with a root_squash NFS export. A cron job copies the files from there to /var/spool/cron/crontabs as you describe. But when the user calls crontab, what happens is that the file is first explicitly copied from the NFS mount, then crontab(1) is invoked, and upon exit, the user crontab is saved back to the NFS. I think this would work fine, don't you think? Sure, if you want to go that way, a wrapper around crontab is fine. that, in addition with an @reboot cron job to initialise /var/spool/cron/crontabs from the NFS mounted /var/local/crontabs did the trick. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: exim or postfix
On Sun, Nov 07, 2004 at 02:02:35PM +0100, martin f krafft wrote: also sprach Brett Parker [EMAIL PROTECTED] [2004.11.07.1226 +0100]: exim4 and postfix, depending on the machine, and who origionally set it up. New machines are getting exim4 because it is far more flexible and powerful that postfix (in my experience). Well, my last tests have shown postfix to be more performant by about a factor of 1.6. In addition, there is the single setuid binary thing about exim. You are right that exim has a lot more features than postfix. However, are they needed? To me, exim tries to be more than an MTA, which is why I surely prefer postfix. I use a fair chunk of them, so yes, I'd say they are. ACLs and the sheer power of the router config wins me over everytime. I work for a small ISP so the more flexible the solution, the better for us. As new things come up, and new unthought of problems arrise, I find that not having to go outside the server setup for large groups of users is rather useful. Coupled with rather powerful database access, exim4 just makes my life a lot easier. There have been some very simple things that I've needed to find solutions to with postfix in the past which I ended up having to do with procmail that I can now deal with in ~ 3 lines in the exim config. Then, I've always prefered exim, I like having control at my finger tips, and things to do what I expect :) Just out of interest, were your tests exim3 or exim4 vs postfix. FWICT there's been a lot of work gone in to exim4, and it does seem to be faster than exim3, I haven't done a straight speed comparison between postfix and exim4, though. Thanks, -- Brett Parker web: http://www.sommitrealweird.co.uk/ email: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: exim or postfix
also sprach Brett Parker [EMAIL PROTECTED] [2004.11.07.1440 +0100]: Then, I've always prefered exim, I like having control at my finger tips, and things to do what I expect :) Ha! Flamebait! Consider yourself whacked. I won't even respond to this. :) /me embraces /etc/postfix/main.cf Just out of interest, were your tests exim3 or exim4 vs postfix. exim3; sorry, I should have mentioned that. FWICT there's been a lot of work gone in to exim4, and it does seem to be faster than exim3, I haven't done a straight speed comparison between postfix and exim4, though. I have not either for exim4. I would be interested though. I am very happy with postfix, but I do at times eye over to the router config of exim. You are right, I cannot get rid of procmail at the moment, which is definitely a pain. However, I've been using postfix for like 7 years now and I really don't want to start to learn to swim again in icy waters. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Limiting User Commands
On Fri, Nov 05, 2004 at 03:35:11PM -0800, Stephen Le wrote: See the example above. Users would still be able to upload their own Perl scripts and get Apache to execute them without restriction - the Perl script could call commands that I want to ban the users from executing. Lots of people have commented already, but I've not seen any discussion on why you might want to do this. What kind of bad commands are you trying to prevent? Most of the dangerous commands like fdisk, etc, will be handled by the existing permissions setup. If you give people the ability to upload CGI scripts, like the perl example you mention, you've already lost - a malicious user could compile some C code statically and exectute that remotely. If you're operating a shared system and want to keep seperate web users isolated from each other using rbash, chroots or similar should be sufficient. What exactly is it that these solutions do not give you which you need? Steve -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
also sprach Steve Kemp [EMAIL PROTECTED] [2004.11.07.1514 +0100]: If you're operating a shared system and want to keep seperate web users isolated from each other using rbash, chroots or similar should be sufficient. Neither rbash not chroots are security measures. They are hurdles at most, but can be easily circumvented. Use virtual machines instead of chroots, and process and filesystem ACLs instead of rbash. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: exim or postfix
On Sun, Nov 07, 2004 at 02:02:35PM +0100, martin f krafft wrote: [...] I can't wait until I have time to try/use/improve Md's policy framework. Do you have an URL with more info about that policy framework?. Thanks, -- teo - http://blog.eltridente.org Res publica non dominetur -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: exim or postfix
also sprach Teófilo Ruiz Suárez [EMAIL PROTECTED] [2004.11.07.1529 +0100]: Do you have an URL with more info about that policy framework?. Not handy. Please write to md ät linux dot it, he's the author. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Limiting User Commands
Steve Kemp writes: If you give people the ability to upload CGI scripts, like the perl example you mention, you've already lost - a malicious user could compile some C code statically and exectute that remotely. No need for C. Perl suffices. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NFS-mounting crontabs
Am 2004-11-07 01:12:49, schrieb Mark Ferlatte: Okay. I guess my next question is: why do you want your user crontabs NFS mounted from your clients? Since they are local configs, why not just let them be local? If you feel that you have to backup your crontabs for each host, have a cronjob on each host that does a cp -a /var/spool/cron /mount/master/srv/var/spool/crontabs/$HOSTNAME, or whatever. And if you have several workstations where you are working ? OK, I have $USER crontabs in ~/.crontab which are loaded if I user login. It is loaded from ~7.bash_profile. Then I have a cronjob which check whether the user is Loged-Out or not and it removed the $USER crontab from /var/spool/crontabs. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Limiting User Commands
On Sun, 7 Nov 2004 14:14:16 +, Steve Kemp [EMAIL PROTECTED] wrote: Lots of people have commented already, but I've not seen any discussion on why you might want to do this. What kind of bad commands are you trying to prevent? Most of the dangerous commands like fdisk, etc, will be handled by the existing permissions setup. For example, as I mentioned in an earlier reply, I might not want normal users to be able to run ftp, telnet, ssh, wget, gcc, or any other number of commands. I still want users to be able to run the bulk of the commands available on the system, though. I might also want to allow another set of users to be able to run the commands unavailable to normal users. In other words, I'd like to restrict normal users more than the default permissions setup. -Stephen Le -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
On Sun, 07 Nov 2004 10:10:31 -0600, John Hasler [EMAIL PROTECTED] wrote: Steve Kemp writes: If you give people the ability to upload CGI scripts, like the perl example you mention, you've already lost - a malicious user could compile some C code statically and exectute that remotely. No need for C. Perl suffices. I should be able to restrict a user's Perl scripts using Apache's suEXEC. I don't see how a user would be able to remotely execute a compiled C program outside of their priviledges. -Stephen Le -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
This one time, at band camp, Stephen Le said: On Sun, 7 Nov 2004 14:14:16 +, Steve Kemp [EMAIL PROTECTED] wrote: Lots of people have commented already, but I've not seen any discussion on why you might want to do this. What kind of bad commands are you trying to prevent? Most of the dangerous commands like fdisk, etc, will be handled by the existing permissions setup. For example, as I mentioned in an earlier reply, I might not want normal users to be able to run ftp, telnet, ssh, wget, gcc, or any other number of commands. I still want users to be able to run the bulk of the commands available on the system, though. I might also want to allow another set of users to be able to run the commands unavailable to normal users. apt-get remove --purge ftp telnet wget gcc rm /usr/bin/ssh /usr/bin/scp I understand your point, but simply don't install the more dangerous things before bending over backwards to make things difficult. As with services, programs not needed should just not be on a server. Part of my monthly audit of systems I look after is to make sure things like gcc and a few others are not installed. Note that neither my approach nor yours really stops someone who is determined - all of the functionality of the above programs could be replicated in perl, python, etc, so you've only made it difficult, not impossible. Then there is ~/bin, where users can stash anything they like, if you don't also regularly search /home for questionable files. Even mounting it noexec isn't really a help - perl /path/to/script works as well as /lib/ld-linux.so.2 /path/to/binary Does not help at all for your original problem, I'm afraid. It looks to me like what you want is filesystem acl's or SELinux to totally lock things down, but others are going to be more helpful with those than I will. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpJS5Xf0lFOX.pgp Description: PGP signature
Re: Limiting User Commands
On Sun, 7 Nov 2004 14:41:42 -0500, Stephen Gran [EMAIL PROTECTED] wrote: apt-get remove --purge ftp telnet wget gcc rm /usr/bin/ssh /usr/bin/scp Unfortunately, I can't do that since I still want some users to be able to access those commands. I just want to restrict access to those commands from most users. I could install those utilities into another directory and set appropriate permissions, but I'd also like system accounts to be able to use them, which complicates matters... Note that neither my approach nor yours really stops someone who is determined - all of the functionality of the above programs could be replicated in perl, python, etc, so you've only made it difficult, not impossible. Then there is ~/bin, where users can stash anything they like, if you don't also regularly search /home for questionable files. Even mounting it noexec isn't really a help - perl /path/to/script works as well as /lib/ld-linux.so.2 /path/to/binary I understand that users could still upload their own programs and run them, but users will do so at the risk of account suspension. Does not help at all for your original problem, I'm afraid. It looks to me like what you want is filesystem acl's or SELinux to totally lock things down, but others are going to be more helpful with those than I will. Well, after a couple of people mentioned filesystem ACLs, I took a look at them. They might be able to accomplish what I need, but I'll have to read more of the documentation. -Stephen Le -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
I wrote: No need for C. Perl suffices. Stephen Le writes: I should be able to restrict a user's Perl scripts using Apache's suEXEC. I don't see how a user would be able to remotely execute a compiled C program outside of their priviledges. I meant that they can do anything with Perl that they can with C. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
On Fri, Nov 05, 2004 at 07:53:33PM +0200, [EMAIL PROTECTED] wrote: In regards to the latter method, would it be possible for me to change the group ownership of the commands I don't want users to have access to and revoke execute permission from that group? Yes, you can make something like that: addgroup(access), then change groupname of commands that you want with that group (access), remember to remove execute/search by others from commands that are with group(access), also don't forget to add group(access) to every user that you want to have access to this commands. The only problem with this approach would be that you'd revoke it from system accounts too, not just your users. It might break in unexpected places. It seems to me that this should be possible with SELinux. What you need would be a role for your users where they are only able to run the commands you want them to run, whereas system accounts would remain unblocked. You just need to add group(access) to that system accounts that you want or that you think that they'll break in unexpected places... Don't you think? -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- SELLINET Internet Services Provider - http://www.sellinet.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gateway to dial-up connections
Hi all, I'm in trouble on setting up a gateway to diul-up users. I'm using iptables with mstate module to masquerade the clients' ip addresses. I have a RAS Server (Ikon 4400) that receives PPP and PPPoE connections. The RAS's gateway is pointing to the server i'm setting up. Now araises the question. When I connect using a PPPoE connection, every website I try to connect works fine, but when a user does a normal dial-up, some sites simply don't open. Just seems to be openning. I thought it was a MTU problem. I changed the mtu at the client side, for test purposes, but it failed again. I Also ckecked the mtu values at the RAS for ppp and pppoe connections. and both were 576 I changed the RAS gateway to another machine with slackware using ipfwadm and kernel 2.0. I didn't setted up this machine. It is the old gateway of the ras. So, After this change, all the clients (ppp + pppoe) could browse the any website. Is that any tip or crick i'm missing to settup my new gateway? Thanks in advance, Nathan Levy. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gateway to dial-up connections
Hi all, I'm in trouble on setting up a gateway to diul-up users. I'm using iptables with mstate module to masquerade the clients' ip addresses. I have a RAS Server (Ikon 4400) that receives PPP and PPPoE connections. The RAS's gateway is pointing to the server i'm setting up. Now araises the question. When I connect using a PPPoE connection, every website I try to connect works fine, but when a user does a normal dial-up, some sites simply don't open. Just seems to be openning. I thought it was a MTU problem. I changed the mtu at the client side, for test purposes, but it failed again. I Also ckecked the mtu values at the RAS for ppp and pppoe connections. and both were 576 I changed the RAS gateway to another machine with slackware using ipfwadm and kernel 2.0. I didn't setted up this machine. It is the old gateway of the ras. So, After this change, all the clients (ppp + pppoe) could browse the any website. Is that any tip or crick i'm missing to settup my new gateway? Thanks in advance, Nathan Levy. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
apt-cacher transition from apache to apache2
[sent this to debian-user, got no suggestions - I hope this is not too OT on this list] On a sarge system, I was using apt-cacher with apache. No problems there. Once I replaced apache with apache2, apt-cacher works but no longer accepts any configuration changes. I.e. changing /etc/apt-cacher/apt-cacher.conf and then reloading/restarting apache2 does not honor the changes. I think it has something to do with the /etc/apt-cacher/apache.conf snippet which I need to install somewhere, but I have no idea where. I checked what bug #250599 says about apache2, and my link does exist: helios:/etc/apache2/mods-enabled# ls -l cgi.load lrwxrwxrwx 1 root root 36 Oct 21 14:52 cgi.load - /etc/apache2/mods-available/cgi.load helios:/etc/apache2/mods-enabled# Could anyone suggest a fix? Thanks -A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-cacher transition from apache to apache2
also sprach Alexandros Papadopoulos [EMAIL PROTECTED] [2004.11.08.0734 +0100]: changing /etc/apt-cacher/apt-cacher.conf and then reloading/restarting apache2 does not honor the changes. Well, you should not need to restart apache2 since apt-cacher is a CGI. Apparently, apache2 loads it permanently though, which is news to me. Does it work at all? I think it has something to do with the /etc/apt-cacher/apache.conf snippet which I need to install somewhere, but I have no idea where. Leave it right there and 'include' it from the vhost definition. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
