restricting user commands
Hi all! I would like to restrict the commands that a specific user can use on my linux box. Could someone please tell me the various options available? thanks ---- Greg, Computer Frontiers International ,,, /'^'\ ( o o ) oOOO--(_)--OOOo---------------------- "Just because you're not paranoid, it doesn't mean they are *not* after you!"
I would like to restrict the commands that a specific user can use on my linux box. This is generally not useful. anyone could compile the commands (maybe on another machine) and put them on your box (except for suid binaries, of course). Linux is a stable and secure OS, you don't really need to block some programs. What you may want to do is to enable the procfs patch (get it from www.openwall.com/linux), which prevents a user to see other users processes. You should also make /tmp in a noexec and nosuid partition and /home also nosuid. then give each user a private tmp directory and set TMPDIR and TEMPDIR to this directory. screen (if you use it) should also be configured to use this private directory. Don't forget to apply patches as soon as they come out.
hth Markus -- _____________________________ /"\ Markus Gaugusch ICQ 11374583 \ / ASCII Ribbon Campaign markus@gaugusch.dhs.org X Against HTML Mail / \
Thanks.... ---- Greg, Computer Frontiers International ,,, /'^'\ ( o o ) oOOO--(_)--OOOo---------------------- "Just because you're not paranoid, it doesn't mean they are *not* after you!" On Mon, 1 Oct 2001, Markus Gaugusch wrote:
I would like to restrict the commands that a specific user can use on my linux box. This is generally not useful. anyone could compile the commands (maybe on another machine) and put them on your box (except for suid binaries, of course). Linux is a stable and secure OS, you don't really need to block some programs. What you may want to do is to enable the procfs patch (get it from www.openwall.com/linux), which prevents a user to see other users processes. You should also make /tmp in a noexec and nosuid partition and /home also nosuid. then give each user a private tmp directory and set TMPDIR and TEMPDIR to this directory. screen (if you use it) should also be configured to use this private directory. Don't forget to apply patches as soon as they come out.
hth Markus
-- _____________________________ /"\ Markus Gaugusch ICQ 11374583 \ / ASCII Ribbon Campaign markus@gaugusch.dhs.org X Against HTML Mail / \
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Hi
I would like to restrict the commands that a specific user can use on my linux box.
Could someone please tell me the various options available?
bash has a restricted mode, see "man bash", and search for "RESTRICTED". Bye Bart Frackiewicz PGP Key ID: 0xBFB9C517
Bart Frackiewicz wrote:
Hi
I would like to restrict the commands that a specific user can use on my linux box.
Could someone please tell me the various options available?
bash has a restricted mode, see "man bash", and search for "RESTRICTED".
which is mostly useless because the user is able to start a new bash which will be unrestricted ... maybe you should 'chroot' the user ... -- intraDAT AG http://www.intradat.com Wilhelm-Leuschner-Strasse 7 Tel: +49 69-25629-0 D - 60329 Frankfurt am Main Fax: +49 69-25629-256
thanks .... ---- Greg, Computer Frontiers International ,,, /'^'\ ( o o ) oOOO--(_)--OOOo---------------------- "Just because you're not paranoid, it doesn't mean they are *not* after you!" On Mon, 1 Oct 2001, Sven Michels wrote:
Bart Frackiewicz wrote:
Hi
I would like to restrict the commands that a specific user can use on my linux box.
Could someone please tell me the various options available?
bash has a restricted mode, see "man bash", and search for "RESTRICTED".
which is mostly useless because the user is able to start a new bash which will be unrestricted ...
maybe you should 'chroot' the user ...
-- intraDAT AG http://www.intradat.com Wilhelm-Leuschner-Strasse 7 Tel: +49 69-25629-0 D - 60329 Frankfurt am Main Fax: +49 69-25629-256
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
* Bart Frackiewicz wrote on Mon, Oct 01, 2001 at 11:43 +0200:
bash has a restricted mode, see "man bash", and search for "RESTRICTED".
Please note, that this is a complex set up. You need a own bin tree for tools which are allowed. You cannot offer ftp (since it can drop a /bin/sh), nor vi (vim only as "rvim") and so on. If you accidently forget such a tool, restrictions are useless. Many unix tools allow excuting external commands! You could copy the allowed tools from /bin and /usr/bin and so on to /home/bin or so, and chmod 700 /bin /usr/bin and so on. The the users could reach tools from /hom/bin only, but I think this breaks a lot of thing if not configured properly. So it's not trivial to set up. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Ar Monday 01 October 2001 8:27 pm, ysgrifenodd greg@space.cfi.co.ug:
Hi all!
I would like to restrict the commands that a specific user can use on my linux box.
Could someone please tell me the various options available?
I use LIDS (www.lids.org) which has an option to stop execution of unsealed commands, and also who can launch sealed commands. Dont know if this is what you want to do, but it works for me.
you can chgrp binaries and remove a user's permission to run them. Of course they can install their own binaries. Mounting /home noexec won't work either. You can try something like restricted shell, just make sure the user can't chsh to something else. As for bash and --restricted that's kind of useless (as someone mentioned you just need to spawn another bash). Chroot works but of course it's a total pain in the butt to do, and the user can still upload binaries/etc in any number of creative ways. There are a couple restricted shells floating aorund that allow you to make a list of what is allowed to run, but there are ways to get around that too (cron for example). Ultimately the best way is to use something like NSA SELinux but that requires a huge amount of effort. Bummer huh. Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/
I don't know if this is already used, but SuSE live eval distribution gives a very robust installation, all the configuration being on the cd, so really protected :-) of course it would be necessary to modify the configuration following needs before burning a cd. at this point it could be possible to remove nearly all the root binaries. do anybody know if SuSE plan to disclose the process of creating this live eval ? it's much smarter than demolinux... it's a different issue than the cd firewall, but of similar concern. jdd -- http://www.dodin.net mailto:jdanield@dodin.net WHO'S THAT GUY ? Help me found it Russia & South america help needed http://www.dodin.net/serge/index.html
Hello, I haven't seen this in the thread yet, but what I do is use /etc/permissions<whatever> to lock out the commands that I don't want normal users to use (like ping, netstat, nmap, etc). It also makes it easy to send out this one file to the 20+ machines in the lab. -Jason
On Mon, 1 Oct 2001, Jason Stover wrote:
Hello,
I haven't seen this in the thread yet, but what I do is use /etc/permissions<whatever> to lock out the commands that I don't want normal users to use (like ping, netstat, nmap, etc).
It also makes it easy to send out this one file to the 20+ machines in the lab.
That works, but it only stops honest users. A dishonest user will just put equivalent commands in his/her own /bin directory and ignore the fact that s/he is denied access to the ones everyone else uses. Ray
On Mon, 1 Oct 2001, Ray Dillinger wrote:
I haven't seen this in the thread yet, but what I do is use /etc/permissions<whatever> to lock out the commands that I don't want normal users to use (like ping, netstat, nmap, etc).
That works, but it only stops honest users. A dishonest user will just put equivalent commands in his/her own /bin directory and ignore the fact that s/he is denied access to the ones everyone else uses.
This should be ommited by mounting the /home filesystem with the noexec flag. cu Michael Muehle
That works, but it only stops honest users. A dishonest user will just put equivalent commands in his/her own /bin directory and ignore the fact that s/he is denied access to the ones everyone else uses. This should be ommited by mounting the /home filesystem with the noexec flag. As Kurt Seifried already said, it is not a 100% solution. noexec can be circumvented, but for the first try it es not so bad.
Markus -- _____________________________ /"\ Markus Gaugusch ICQ 11374583 \ / ASCII Ribbon Campaign markus@gaugusch.dhs.org X Against HTML Mail / \
Markus Gaugusch wrote:
As Kurt Seifried already said, it is not a 100% solution. noexec can be circumvented, but for the first try it es not so bad.
maybe a combination of chrooting, quota, no exec and removed binarys is a good way?:) chroot to safe the rest of the maschine (yes, i know, chroot can be br0ken) quota to stops the user from compiling no exec for the ones who dunno how to exec a bin anyway ;) and removed binarys to restrict the possibilities (like no compiler etc.) another way may be usermode linux .. for every user a own system ;) diskspace is not much expensive today ...and CPU etc. also ... and you can backup this linux from the master maschine so if somebody killed his box, just copy the files back ... -- intraDAT AG http://www.intradat.com Wilhelm-Leuschner-Strasse 7 Tel: +49 69-25629-0 D - 60329 Frankfurt am Main Fax: +49 69-25629-256
maybe a combination of chrooting, quota, no exec and removed binarys is a good way?:)
chroot to safe the rest of the maschine (yes, i know, chroot can be br0ken) quota to stops the user from compiling
? So you're not going to let them store data, or use lynx with cookies?
no exec for the ones who dunno how to exec a bin anyway ;)
then their chroot will be a bit broken if nothing can exec.
and removed binarys to restrict the possibilities (like no compiler etc.)
uploading stuff is possible through so many things (sed and awk!).
another way may be usermode linux .. for every user a own system ;) diskspace is not much expensive today ...and CPU etc. also ... and you can backup this linux from the master maschine so if somebody killed his box, just copy the files back ...
-Kurt
quota to stops the user from compiling
? So you're not going to let them store data, or use lynx with cookies? no, i'm going to let them storage only a few files/bytes whatever...
Kurt Seifried wrote: the question is, for what you need the account? if its a upload account for a homepage, you don't need shell access ...
no exec for the ones who dunno how to exec a bin anyway ;) then their chroot will be a bit broken if nothing can exec. i don't say nothing... but try to find out whats needed to executed and the rest don't need execrights...
and removed binarys to restrict the possibilities (like no compiler etc.)
uploading stuff is possible through so many things (sed and awk!). yeah but you need space ;)
-- intraDAT AG http://www.intradat.com Wilhelm-Leuschner-Strasse 7 Tel: +49 69-25629-0 D - 60329 Frankfurt am Main Fax: +49 69-25629-256
On Mon, 1 Oct 2001, [ISO-8859-1] Michael M�hle wrote:
On Mon, 1 Oct 2001, Ray Dillinger wrote:
I haven't seen this in the thread yet, but what I do is use /etc/permissions<whatever> to lock out the commands that I don't want normal users to use (like ping, netstat, nmap, etc).
That works, but it only stops honest users. A dishonest user will just put equivalent commands in his/her own /bin directory and ignore the fact that s/he is denied access to the ones everyone else uses.
This should be ommited by mounting the /home filesystem with the noexec flag.
I am newbie... how is the /home filesystem mounted with the noexec flag???
cu
Michael Muehle
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
www.seifried.org/lasg/
Kurt Seifried, kurt@seifried.org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://www.seifried.org/security/
----- Original Message -----
From:
On Mon, 1 Oct 2001, Ray Dillinger wrote:
I haven't seen this in the thread yet, but what I do is use /etc/permissions<whatever> to lock out the commands that I don't want normal users to use (like ping, netstat, nmap, etc).
That works, but it only stops honest users. A dishonest user will just put equivalent commands in his/her own /bin directory and ignore the fact that s/he is denied access to the ones everyone else uses.
This should be ommited by mounting the /home filesystem with the noexec flag.
I am newbie... how is the /home filesystem mounted with the noexec flag???
cu
Michael Muehle
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
* Kurt Seifried wrote on Mon, Oct 01, 2001 at 04:12 -0600:
you can chgrp binaries and remove a user's permission to run them. Of course they can install their own binaries.
This can be prevented by disallowing write access to the $PATH and protecting $PATH via rbash (same as bash --restricted)
Mounting /home noexec won't work either.
at least as long as the dyna linker is runnable :)
You can try something like restricted shell, just make sure the user can't chsh to something else. As for bash and --restricted that's kind of useless (as someone mentioned you just need to spawn another bash).
No, this can be prevented. The rbash is designed to work, those people are not such silly :) But it's non-trivial to set up. If the user is not allowed to launch /bin/bash, then take of that path of the $PATH. Use /home/bin or so. Of course drop rbash to /home/bin only. Be really carefull with the tools. Do not allow any complex thing (no ftp and so). Only cat and such things. No perl, no awk and so on. Well, finally you must ask if there are tools left to work with :) * Ray Dillinger wrote on Mon, Oct 01, 2001 at 11:01 -0700:
That works, but it only stops honest users. A dishonest user will just put equivalent commands in his/her own /bin directory
See bash man page. The user cannot launch own binaries: steffen@dx:~ > rbash steffen@dx:~ > ./x.pl rbash: ./x.pl: restricted: cannot specify `/' in command names steffen@dx:~ > export PATH=. rbash: PATH: readonly variable steffen@dx:~ > cd .. rbash: cd: restricted But of course, you have to set up it correctly like all other things. I set up such an environment, but users cannot do much useful things... :)
and ignore the fact that s/he is denied access to the ones everyone else uses.
But not with rbash :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Monday 01 October 2001 12:27, greg@space.cfi.co.ug wrote:
Hi all!
I would like to restrict the commands that a specific user can use on my linux box. [snip]
Hi, ACL stuff: http://acl.bestbits.at/ (they have a mailing list) http://www.nsa.gov/selinux (they have a mailing list, too) http://www.tzi.de/~agbs/live/acl_emg.html http://research-cistw.saic.com/cace/ John
thanks... ---- Greg, Computer Frontiers International ,,, /'^'\ ( o o ) oOOO--(_)--OOOo---------------------- "Just because you're not paranoid, it doesn't mean they are *not* after you!" On Mon, 1 Oct 2001, John Pinder wrote:
On Monday 01 October 2001 12:27, greg@space.cfi.co.ug wrote:
Hi all!
I would like to restrict the commands that a specific user can use on my linux box. [snip]
Hi,
ACL stuff:
http://acl.bestbits.at/ (they have a mailing list) http://www.nsa.gov/selinux (they have a mailing list, too) http://www.tzi.de/~agbs/live/acl_emg.html http://research-cistw.saic.com/cace/
John
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
participants (12)
-
Bart Frackiewicz -
elfed lewis -
greg＠space.cfi.co.ug -
Jason Stover -
jdd -
John Pinder -
Kurt Seifried -
Markus Gaugusch -
Michael Mühle -
Ray Dillinger -
Steffen Dettmer -
Sven Michels