Re: Limiting User Commands
On Wednesday 10 November 2004 21:49, "Ben Hutchings" <[EMAIL PROTECTED]> wrote: > > I feel the need to learn something new today. How could the user replace > > the root owned files in a directory that they own? > > By renaming or unlinking them. Linux treats this as an operation on the > directory, not the file, so it's controlled by the directory's permissions. SE Linux has finer grained access control. So you can allow a user to have write access to their home directory but give ~/.bashrc etc a different type that permits only read, getattr, and execute access (but not write, append, unlink, link, rename, setattr, lock, ioctl, or create). I periodically run SE Linux play machines setup in this manner. I have some files in the root user's home directory that they can only read and execute, some that they can read and append to, and the default is for full access to files in the home directory. I'll have my play machine back online soon, see my web page for the details. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
On Sat, 20 Nov 2004 07:36:05 -0700, Wesley J Landaker <[EMAIL PROTECTED]> wrote: > On Sunday, 07 November 2004 18:14, [EMAIL PROTECTED] wrote: > > 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? > > Why not do this the other way around--it should be much simpler, and > only affects users you specifically touch: > > e.g. add users you don't want to run /usr/bin/prog1 to the group > "noexecprog1", set the permissions of /usr/bin/prog1 to 705 and make > the owner:group root:noexecprog1. Now anyone in the group noexecprog1 > can't read or execute the program, but anyone else can. I decided to implement group-based access policies using a method similar to what is described above. I enabled filesystem ACLs and created a system group called "untrusted." I added all users I wanted to restrict to the "untrusted" group and removed group members' access to certain commands by executing "setfacl -m g:untrusted:--- ". This method provides more flexibility than the standard Linux owner, group, and other permissions because I can also create a "semi-trusted" group and have different policies for that group. Additionally, with ACL, I can enable commands on a user-by-user basis if a user demonstrates that they need access to a normally restricted command. Regarding CGI scripts written by users, I've enabled Apache's suEXEC, which runs scripts as their owner, thus respecting the owner's permissions. Unfortunately, I couldn't do the same with PHP. I could use the CGI version of PHP, but there'd be a performance hit and users would have to modify their PHP scripts to include a shabang line at the top. I also considered running PHP in safe mode, but many popular scripts don't run under safe mode, such as gallery. To resolve the issue with PHP, I decided to add Apache's user, "www-data," to "untrusted". Everything seems to be working fine. Oh, and I've enabled process accounting. If a user does indeed find a way to execute a restricted command without permission, I'll find out about it. -Stephen Le -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
On Sunday, 07 November 2004 18:14, [EMAIL PROTECTED] wrote: > 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? Why not do this the other way around; it's much simpler: e.g. add users you don't want to run /usr/bin/prog1 to the group "noexecprog1", set the permissions of /usr/bin/prog1 to 705 and make the owner:group root:noexecprog1. Now anyone in group noexecprog1 can read/execute /usr/bin/prog1, but anyone else can. Only affects users you specifically touch. -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpbVvNHbPjf8.pgp Description: PGP signature
Re: Limiting User Commands
Michael Graham wrote: /tmp/test$ ll total 0 -rw-r--r-- 1 root root 0 2004-11-15 00:36 test /tmp/test$ ll -d ../test/ drwxr-xr-t 2 mick mick 4.0K 2004-11-15 00:36 ../test/ /tmp/test$ rm test rm: remove write-protected regular empty file `test'? y /tmp/test$ ll total 0 But according to the man page of chmod I shouldn't be able to do this: Interesting. I notice that after a `chown root:root /tmp/test', the file /tmp/test/test cannot be removed any more by the normal user. So, I suppose the fact that mick can remove the file /tmp/test/test is related to the fact that /tmp/test is owned by mick (or 'joostje' in my case). There is some logic to it, because if the kernel didn't allow mick to remove /tmp/test/test, mick could simply first run chmod u-t /tmp/test and then repeat the rm /tmp/test/test successfully. -- Groetjes joostje 47d3fcfe28f2a83497e79d9bc7d5087c-4a1ee1fddab4648175518cb4c1c9edb3ed0e89f0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Limiting User Commands
On Tue, 09 Nov 2004 20:58:33 +0100, Dan Roozemond wrote: > Suppose the root-owned file (readable for non-root user) is a. Then one does > 'cp a b; rm a; mv b a' and we have the same file a owned by the regular > user. Key observation here is that the non-root user ownes the directory, > hence can remove files. Thanks for the info. When I was playing around with this I discovered something quite strange: /tmp/test$ ll total 0 -rw-r--r-- 1 root root 0 2004-11-15 00:36 test /tmp/test$ ll -d ../test/ drwxr-xr-t 2 mick mick 4.0K 2004-11-15 00:36 ../test/ /tmp/test$ rm test rm: remove write-protected regular empty file `test'? y /tmp/test$ ll total 0 But according to the man page of chmod I shouldn't be able to do this: When the sticky bit is set on a directory, files in that directory may be unlinked or renamed only by root or their owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable. Does anyone understand this? -- OoberMick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
Michael Graham wrote: Ben Hutchings wrote: Christopher Swingley wrote: Change the ownership and permissions on their .bash_profile and .bashrc to root:root 644: -rw-r--r--1 root root 420 Sep 21 13:05 .bash_profile -rw-r--r--1 root root 746 Sep 21 13:05 .bashrc You should also add the sticky bit to their directory (chmod +t) to prevent them from replacing these files. I feel the need to learn something new today. How could the user replace the root owned files in a directory that they own? By renaming or unlinking them. Linux treats this as an operation on the directory, not the file, so it's controlled by the directory's permissions. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
On Tue, 09 Nov 2004 17:43:19 -0500, Doug Griswold <[EMAIL PROTECTED]> wrote: > can upload the changes. You will get tired of that real quick. Other > than this method there is always a what if factor selinux,chroot, > virtual server etc... The point is to minimize the "what if" factors by choosing the most effective means to accomplish what I want done. No method is perfect, but some methods are certainly better than others. -Stephen Le -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
Don't give them shell access, and don't let them ftp to the server. Make them email you all the changes so you can browse for bad code. Then you can upload the changes. You will get tired of that real quick. Other than this method there is always a what if factor selinux,chroot, virtual server etc... Even if they do upload a bad script they shouldn't have perms to do anything. You could allow the apache user to rm -rf /* and nothing would happen if setup correctly. >>> Stephen Le <[EMAIL PROTECTED]> 11/09/04 5:16 PM >>> On Mon, 8 Nov 2004 09:28:10 -0900, Christopher Swingley <[EMAIL PROTECTED]> wrote: > Make symbolic links between allowed commands and '/usr/local/rbin' > > As I said before, this is just a simple attempt to reduce priviledge. > There are undoubtably ways around it, some easier than others depending > on what's in /usr/local/rbin. This won't prevent users from executing banned commands with Perl scripts called by Apache. I'm opposed to using rbash for this reason and because some users might want to use a non-bash shell. -Stephen Le -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
On Mon, 8 Nov 2004 09:28:10 -0900, Christopher Swingley <[EMAIL PROTECTED]> wrote: > Make symbolic links between allowed commands and '/usr/local/rbin' > > As I said before, this is just a simple attempt to reduce priviledge. > There are undoubtably ways around it, some easier than others depending > on what's in /usr/local/rbin. This won't prevent users from executing banned commands with Perl scripts called by Apache. I'm opposed to using rbash for this reason and because some users might want to use a non-bash shell. -Stephen Le -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
On Tue, Nov 09, 2004 at 07:15:01PM +, Michael Graham wrote: > Ben Hutchings wrote: > > Christopher Swingley wrote: > >> Change the ownership and permissions on their .bash_profile and .bashrc > >> to root:root 644: > >> > >> -rw-r--r--1 root root 420 Sep 21 13:05 > >> .bash_profile -rw-r--r--1 root root 746 Sep 21 > >> 13:05 .bashrc > > > > You should also add the sticky bit to their directory (chmod +t) to > > prevent them from replacing these files. > > I feel the need to learn something new today. How could the user replace > the root owned files in a directory that they own? I think they could do rm -r dir_in_question to remove the directory. (At least I can on my system. I get asked if I want to remove a write-protected file, then it gets removed.) Prior to that you could move all the files you want to keep to new directory and then move them back when you've finished. Then add your own replacement to the deleted root-owned file. > > -- > OoberMick > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- David Jardine "Running Debian GNU/Linux and loving every minute of it." -Sacher M. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Limiting User Commands
> I feel the need to learn something new today. How could the > user replace > the root owned files in a directory that they own? > Suppose the root-owned file (readable for non-root user) is a. Then one does 'cp a b; rm a; mv b a' and we have the same file a owned by the regular user. Key observation here is that the non-root user ownes the directory, hence can remove files. HTH Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
Ben Hutchings wrote: > Christopher Swingley wrote: >> Change the ownership and permissions on their .bash_profile and .bashrc >> to root:root 644: >> >> -rw-r--r--1 root root 420 Sep 21 13:05 >> .bash_profile -rw-r--r--1 root root 746 Sep 21 >> 13:05 .bashrc > > You should also add the sticky bit to their directory (chmod +t) to > prevent them from replacing these files. I feel the need to learn something new today. How could the user replace the root owned files in a directory that they own? -- OoberMick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
Christopher Swingley wrote: This is what I've done when I wanted to reduce the set of commands a user could run. I'm sure a reasonably competant Unix user could easily circumvent these restrictions, but it's a good first start, and making such attempts would result in account suspension. Change their shell to /bin/rbash in /etc/passwd: bbonds:x:50539:50539:Barry Bonds,,,:/home/bbonds:/bin/rbash Change the ownership and permissions on their .bash_profile and .bashrc to root:root 644: -rw-r--r--1 root root 420 Sep 21 13:05 .bash_profile -rw-r--r--1 root root 746 Sep 21 13:05 .bashrc You should also add the sticky bit to their directory (chmod +t) to prevent them from replacing these files. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
Greetings, * Osamu Aoki <[EMAIL PROTECTED]> [2004-Nov-05 14:13 AKST]: > On Fri, Nov 05, 2004 at 09:31:21AM -0800, Stephen Le wrote: > > Is there an easy way to limit the commands a certain group of users > > can execute? > > I never done this but.. > > Use of chroot with bash started as rbash sems to be what you need. > > Or use of rbash with with PATH pointing to custom location where > commands exist. This is what I've done when I wanted to reduce the set of commands a user could run. I'm sure a reasonably competant Unix user could easily circumvent these restrictions, but it's a good first start, and making such attempts would result in account suspension. Change their shell to /bin/rbash in /etc/passwd: bbonds:x:50539:50539:Barry Bonds,,,:/home/bbonds:/bin/rbash Change the ownership and permissions on their .bash_profile and .bashrc to root:root 644: -rw-r--r--1 root root 420 Sep 21 13:05 .bash_profile -rw-r--r--1 root root 746 Sep 21 13:05 .bashrc Modify the PATH in whichever file you wish to a PATH that only includes the commands you wish: export PATH="/usr/local/rbin" Make symbolic links between allowed commands and '/usr/local/rbin' As I said before, this is just a simple attempt to reduce priviledge. There are undoubtably ways around it, some easier than others depending on what's in /usr/local/rbin. Chris -- Christopher S. Swingley email: [EMAIL PROTECTED] (work) Intl. Arctic Research Center[EMAIL PROTECTED] (personal) University of Alaska Fairbanks www.frontier.iarc.uaf.edu/~cswingle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
On Mon, Nov 08, 2004 at 03:14:53AM +0200, [EMAIL PROTECTED] wrote: > > 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? Yes, that would work, but only for as long as you don't add other system accounts. This would mean that you would have to remember to check whether a newly-installed package created a new system account, and if so, that you have to add it to the group, if required. I think this would probably break at some point, whereas the same is not true with the SELinux setup (additionally, this will give you increased security, which is nice too) -- 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: 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]
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 Sun, 2004-11-07 at 14:54, Stephen Le wrote: > > > 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. > Wouldnt the folks that are scared of account suspension be the least likely threats? It's the folks that are willing to do stuff that they're not supposed to that are problematic. -davidc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
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 | - pgpZ4n5vGVSli.pgp Description: PGP signature
RE: Limiting User Commands
> 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. You'd have to realize that although you might be able to forbid people to run /usr/bin/someprogram, you very likely won't be able to forbid them to download something (maybe someprogram, or anything else) to their home directory, and then execute that program, thus making your restrictions void. If you want to enable the users to run only say 4 or 5 different programs, you might want to write a script presenting a menu, where they can make a selection, and then one of the five programs is ran. Then, you set the user's shell to that script. As stated above, I doubt if you can restrict them enough if you give them a bash shell. HTH Dan -- 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
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
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: 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: 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: Limiting User Commands
> On Fri, 5 Nov 2004 19:53:33 +0200 (EET), [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: >> 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 thing I'm worried about with that method is whether a user > would be able to run commands that they aren't supposed to have access > to if they write a Perl script calling one of the banned commands and > getting Apache to execute that script. In other words, would the > script execute with the script owner's priviledges or with Apache's > priviledges? > If the user who execute forbidden command have no additional-group(access) then he'll get "permission denied" no matter that he execute command from perl, php and etc. Just remember that user who can execute forbidden command s must have addition-group(access) any other users that don't have this group have no access to forbidden commands, including user that run apache. And one more thing you need to remove "read by others" and "execute/search by others" from forbidden commands, also you need to change theire groupname. Example: chmod 750 /bin/rm ; chown root.access /bin/rm ; usermod -G access user > Thanks, > Stephen Le > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > -- SELLINET Internet Services Provider - http://www.sellinet.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
On Sat, Nov 06, 2004 at 11:21:43AM -0800, Stephen Le wrote: > On Sat, 6 Nov 2004 12:43:27 -0500, Kevin Mark > <[EMAIL PROTECTED]> wrote: > > I think it is worth the extra 'sudo'. People should learn the difference > > between regular commands and special commands. you can have sudo ask for > > a password or not. Ubuntu uses a sudo-like thing. Users should be asked > > to do an extra step for commands that are not 'normal' for a reason. the > > idea like 'think twice, type one' is good for such commands. > > I'm well aware that sudo can be configured to not ask for passwords, > but as I stated in a reply to another person suggesting that I use > sudo, I'm not trying to grant access to any special commands. Rather, > I'm trying to limit the commands users can run to a certain subset. > For example, I might not want regular users to be able to run ftp or > telnet. > > If I were to use sudo, I would have to remove execute access from all > commands and grant them on a command by command basis, requiring each > users to prefix _every_ command with 'sudo'. > > -Stephen Le Hi Stephen, if U is all the commands a regular user can execute and X is the set of commands you want them to have access to: X is _ near 90% or near 10%? if its near 90% I have an idea. if its U closer to 10%, then maybe a chroot is better? -Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ "Have you mooed today?"... signature.asc Description: Digital signature
Re: Limiting User Commands
On Sat, 6 Nov 2004 16:55:33 +0100, Lukas Ruf <[EMAIL PROTECTED]> wrote: > > If they got Apache to execute the script, the "bad_command" would be > > run. This is the reason why I'm trying to approach this problem from > > a permissions standpoint. Of course, someone might suggest running > > an Apache daemon inside each user's chroot, but that's really > > impractical... > > > > if apache is run in a chroot'ed environment, wouldn't this solve > exactly the problem? I run my "public" web-server that way together > with the suexec feature enabled such that a script is executed as the > owner of the directory/user, hence I feel pretty safe in that regard. I'm running Apache in a virtual-hosting environment with multiple users. If I understand Apache chroot'ing correctly, that would mean I would have to run a different Apache process for every user (one Apache process per each user's chroot), and that would only be the minimum number of Apache processes I would have to be running. As you can see, as the number of users grow and the traffic to each of their websites increases, the number of independent Apache processes running could get out of hand. However, suEXEC looks like the tool I need to ensure that a user's Perl scripts run with their priviledges and not Apache's. Do you know if suEXEC would also apply to PHP scripts? Thanks, Stephen Le -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
On Sat, 6 Nov 2004 12:43:27 -0500, Kevin Mark <[EMAIL PROTECTED]> wrote: > I think it is worth the extra 'sudo'. People should learn the difference > between regular commands and special commands. you can have sudo ask for > a password or not. Ubuntu uses a sudo-like thing. Users should be asked > to do an extra step for commands that are not 'normal' for a reason. the > idea like 'think twice, type one' is good for such commands. I'm well aware that sudo can be configured to not ask for passwords, but as I stated in a reply to another person suggesting that I use sudo, I'm not trying to grant access to any special commands. Rather, I'm trying to limit the commands users can run to a certain subset. For example, I might not want regular users to be able to run ftp or telnet. If I were to use sudo, I would have to remove execute access from all commands and grant them on a command by command basis, requiring each users to prefix _every_ command with 'sudo'. -Stephen Le -- 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 01:19:53PM -0800, Stephen Le wrote: > On Fri, 5 Nov 2004 18:40:59 +0100, Benedict Verheyen > <[EMAIL PROTECTED]> wrote: > > Sounds like you want sudo. > > I don't think sudo is appropriate for what I'm trying to do. I'd like > users to have limited shell access; I'm not trying to give them access > to special commands. Besides, telling users to prefix every command > they run with 'sudo' would be awkward and cumbersome. Hi Stephen, I think it is worth the extra 'sudo'. People should learn the difference between regular commands and special commands. you can have sudo ask for a password or not. Ubuntu uses a sudo-like thing. Users should be asked to do an extra step for commands that are not 'normal' for a reason. the idea like 'think twice, type one' is good for such commands. -Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ "Have you mooed today?"... signature.asc Description: Digital signature
Re: Limiting User Commands
> Stephen Le <[EMAIL PROTECTED]> [2004-11-06 00:36]:
>
> On Sat, 6 Nov 2004 00:13:28 +0100, Osamu Aoki <[EMAIL PROTECTED]>
> wrote:
> > > Is there an easy way to limit the commands a certain group of
> > > users can execute? I've looked at chroot, and it's too
> > > complicated for my needs and seems too easy to circumvent; users
> > > will be able to upload their own Perl scripts, so it seems that
> > > they'll be able to access commands outside their chroot by
> > > getting Apache w/ mod_perl to execute the script.
> >
> > Is is so?
>
> Indeed. A chroot would only apply to a user if they were logged into
> the system. Let's say I wanted to prevent users executing the
> command "bad_command". Well, if "bad_command" was not available to a
> user in their chroot, they wouldn't be able to execute it. However,
> a user might write a Perl script that contained the following line:
>
> system("bad_command");
>
> If they got Apache to execute the script, the "bad_command" would be
> run. This is the reason why I'm trying to approach this problem from
> a permissions standpoint. Of course, someone might suggest running
> an Apache daemon inside each user's chroot, but that's really
> impractical...
>
if apache is run in a chroot'ed environment, wouldn't this solve
exactly the problem? I run my "public" web-server that way together
with the suexec feature enabled such that a script is executed as the
owner of the directory/user, hence I feel pretty safe in that regard.
HTH.
wbr,
Lukas
--
Lukas Ruf | Wanna know anything about raw |
| IP? -> |
eMail Style Guide: |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
On 06.11.2004 00:35 Stephen Le wrote:
Is there an easy way to limit the commands a certain group of users
can execute?
Indeed. A chroot would only apply to a user if they were logged into
the system. Let's say I wanted to prevent users executing the command
"bad_command". Well, if "bad_command" was not available to a user in
their chroot, they wouldn't be able to execute it. However, a user
might write a Perl script that contained the following line:
system("bad_command");
If they got Apache to execute the script, the "bad_command" would be
run. This is the reason why I'm trying to approach this problem from a
permissions standpoint.
RSBAC could solve that easily, I prefer the RC module. Default is
neither Apache nor the user is allowed to execute anything. Give the
commands the user is allowed to execute a new RC type and give the user
and Apache execute rights on that type.
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
On Sat, 6 Nov 2004 00:13:28 +0100, Osamu Aoki <[EMAIL PROTECTED]> wrote:
> > Is there an easy way to limit the commands a certain group of users
> > can execute? I've looked at chroot, and it's too complicated for my
> > needs and seems too easy to circumvent; users will be able to upload
> > their own Perl scripts, so it seems that they'll be able to access
> > commands outside their chroot by getting Apache w/ mod_perl to execute
> > the script.
>
> Is is so?
Indeed. A chroot would only apply to a user if they were logged into
the system. Let's say I wanted to prevent users executing the command
"bad_command". Well, if "bad_command" was not available to a user in
their chroot, they wouldn't be able to execute it. However, a user
might write a Perl script that contained the following line:
system("bad_command");
If they got Apache to execute the script, the "bad_command" would be
run. This is the reason why I'm trying to approach this problem from a
permissions standpoint. Of course, someone might suggest running an
Apache daemon inside each user's chroot, but that's really
impractical...
> Use of chroot with bash started as rbash sems to be what you need.
>
> Or use of rbash with with PATH pointing to custom location where
> commands exist.
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.
-Stephen Le
--
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 09:31:21AM -0800, Stephen Le wrote: > Hello all, > > Is there an easy way to limit the commands a certain group of users > can execute? I've looked at chroot, and it's too complicated for my > needs and seems too easy to circumvent; users will be able to upload > their own Perl scripts, so it seems that they'll be able to access > commands outside their chroot by getting Apache w/ mod_perl to execute > the script. Is is so? > I'd like to be able to compile a list of commands/programs that users > in a certain group will be able to execute (ex. cp, mv, rm, etc). > However, I'd also be happy to compile a list of commands users > shouldn't be able to execute. 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? I never done this but.. Use of chroot with bash started as rbash sems to be what you need. Or use of rbash with with PATH pointing to custom location where commands exist. See "man rbash" and "man chroot" "man dbootstrap" etc. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
On Fri, 5 Nov 2004 18:40:59 +0100, Benedict Verheyen <[EMAIL PROTECTED]> wrote: > Sounds like you want sudo. I don't think sudo is appropriate for what I'm trying to do. I'd like users to have limited shell access; I'm not trying to give them access to special commands. Besides, telling users to prefix every command they run with 'sudo' would be awkward and cumbersome. -Stephen Le -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
On Fri, 5 Nov 2004 19:53:33 +0200 (EET), [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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 thing I'm worried about with that method is whether a user would be able to run commands that they aren't supposed to have access to if they write a Perl script calling one of the banned commands and getting Apache to execute that script. In other words, would the script execute with the script owner's priviledges or with Apache's priviledges? Thanks, Stephen Le -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
Take a look at sudo. >>> Stephen Le <[EMAIL PROTECTED]> 11/5/2004 12:31:21 PM >>> Hello all, Is there an easy way to limit the commands a certain group of users can execute? I've looked at chroot, and it's too complicated for my needs and seems too easy to circumvent; users will be able to upload their own Perl scripts, so it seems that they'll be able to access commands outside their chroot by getting Apache w/ mod_perl to execute the script. I'd like to be able to compile a list of commands/programs that users in a certain group will be able to execute (ex. cp, mv, rm, etc). However, I'd also be happy to compile a list of commands users shouldn't be able to execute. 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? Thanks, Stephen Le -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Limiting User Commands
> Hello all, > > Is there an easy way to limit the commands a certain group of users > can execute? I've looked at chroot, and it's too complicated for my > needs and seems too easy to circumvent; users will be able to upload > their own Perl scripts, so it seems that they'll be able to access > commands outside their chroot by getting Apache w/ mod_perl to execute > the script. > > I'd like to be able to compile a list of commands/programs that users > in a certain group will be able to execute (ex. cp, mv, rm, etc). > However, I'd also be happy to compile a list of commands users > shouldn't be able to execute. >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. > > Thanks, > Stephen Le > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > -- SELLINET Internet Services Provider - http://www.sellinet.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Limiting User Commands
>-Oorspronkelijk bericht- >Van: Stephen Le [mailto:[EMAIL PROTECTED] >Verzonden: vrijdag 5 november 2004 18:31 >Aan: [EMAIL PROTECTED]; [EMAIL PROTECTED] >Onderwerp: Limiting User Commands > > >Hello all, > >Is there an easy way to limit the commands a certain group of users >can execute? I've looked at chroot, and it's too complicated for my >needs and seems too easy to circumvent; users will be able to upload >their own Perl scripts, so it seems that they'll be able to access >commands outside their chroot by getting Apache w/ mod_perl to execute >the script. > >I'd like to be able to compile a list of commands/programs that users >in a certain group will be able to execute (ex. cp, mv, rm, etc). >However, I'd also be happy to compile a list of commands users >shouldn't be able to execute. 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? > >Thanks, >Stephen Le Sounds like you want sudo. Regards, Benedict ** Message from InterScan E-Mail VirusWall NT ** ** No virus found in attached file noname.htm This message has been scanned, and is intended to be virus-free. * End of message ***
Limiting User Commands
Hello all, Is there an easy way to limit the commands a certain group of users can execute? I've looked at chroot, and it's too complicated for my needs and seems too easy to circumvent; users will be able to upload their own Perl scripts, so it seems that they'll be able to access commands outside their chroot by getting Apache w/ mod_perl to execute the script. I'd like to be able to compile a list of commands/programs that users in a certain group will be able to execute (ex. cp, mv, rm, etc). However, I'd also be happy to compile a list of commands users shouldn't be able to execute. 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? Thanks, Stephen Le -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
