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:--- <path_to_command>". 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]