[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Limiting User Commands



On Sat, 20 Nov 2004 07:36:05 -0700, Wesley J Landaker <wjl@icecavern.net> wrote:
> On Sunday, 07 November 2004 18:14, ea@sellinet.net 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



Reply to: