Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

SELinux - CentOSx86_64: User command limitation

Is SELinux the right tool for this job? If so, what is the best way to do it?

I would like to limit a particular user to only running some list of pre-defined commands/scripts (perhaps in their home directory). In addition the users scripts could have permission to run commands that the user cannot run directly (e.g. the user script test.sh could call 'ping localhost' but the user could not call 'ping localhost' directly from the command line). It is worth mentioning that I think these limitations are only required for one user account (I will not need multiple different configurations for different user accounts).

The OS is CentOSx86_64 and SELinux is enabled as follows:

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

I am very new to SELinux but have experimented with the following:

(1) I thought that the MLS policy would perhaps be best suited (This link looked promising: http://www.centos.org/docs/5/html/Deployment_Guide-en-US/sec-mcs-getstarted.html) for this task so I first attempted to switch this on. The 'SELinux Admin GUI' does not provide any option to change the policy from targeted so I attempted to directly change /etc/selinux/config. This ended with 'kernel panic' after rebooting so I decided to use the original installed policy (i.e. targeted).

(2) From the SELinux Admin GUI I created a new policy with a policy type of 'Minimal Terminal User Role'. For the 'name' I called it 'limiteduser'. I selected no roles that it would be transitioned to. I selected no additional roles. I selected 'All' TCP and UDP ports for binds/connects. I added no booleans to the policy. After running the generated .sh the new SELinux User and Role were created. I then assigned a login name to the 'limiteduser'. As expected this gave me a user with very limited privileges.

(3) Initially this new user could create a script in its home directory but could not execute it. After I set a boolean called 'allow_guest_exec_content' the user was able to execute the script. Initially the script just contained an 'echo' but once I changed this to ping it failed again. In an attempt to allow 'ping' for this new user I deselected the boolean user_ping (although I think this only applies to user_u rather than guest_u). To do what I want, I think an alternative might be to define a 'user_u' based type and then remove permissions (rather than go with the approach I have taken which is to go with a guest_u based type and add permissions - However I don't know how to do that either!).

(4) A number of online sources discuss policy files from a src directory but this was not installed and I could not figure out which package to install that would add this. I have the following selinux related packages installed:

libselinux.x86_64                   2.0.94-5.3.el6                     installed
libselinux-devel.x86_64             2.0.94-5.3.el6                     installed
libselinux-python.x86_64            2.0.94-5.3.el6                     installed
libselinux-utils.x86_64             2.0.94-5.3.el6                     installed
selinux-policy.noarch               3.7.19-126.el6_2.4                 @updates 
selinux-policy-targeted.noarch      3.7.19-126.el6_2.4                 @updates 
setools-console.x86_64              3.3.7-4.el6                        @base    
setools-devel.x86_64                3.3.7-4.el6                        @base    
setools-gui.x86_64                  3.3.7-4.el6                        @base    
setools-libs.x86_64                 3.3.7-4.el6                        @base    
setools-libs-java.x86_64            3.3.7-4.el6                        @base    
setools-libs-python.x86_64          3.3.7-4.el6                        @base    
setools-libs-tcl.x86_64             3.3.7-4.el6                        @base 

(5) I looked at an alternative limited shell such as http://lshell.ghantoos.org/ but my company requirement is either to use SELinux -or- if all fails to use something already provided by the os (e.g. bash restricted) but this may not be as secure.

I think that I need to define a custom policy and within that:

(a) Allow the user to execute files in its home directory.

(b) Allow the user scripts to transition into different types in order to run commands that the user does not have permissions for.

Using the SELinux admin GUI (and the configuration files I am aware of) I have not idea how to do this.

Thanks for any help you can provide.

share|improve this question
1  
Whilst you're dealing with security, this is more of an administrative question. We don't really deal with specific configuration and system administration questions here. I think it'd probably be better on SuperUser. I've flagged for a moderator to come take a look, and they'll migrate it if neccessary. –  Polynomial Nov 22 '12 at 11:54
1  
This is an awesome question. Im kind of anxious to see the resolution –  midnightsteel Nov 23 '12 at 12:39
add comment

migrated from security.stackexchange.com Nov 23 '12 at 8:21

This question came from our site for Information security professionals.

1 Answer

As you suggested, rbash provides more or less the sort of thing you're after. It limites execution to only the executables already in your PATH, and prohibits changing much of the details of the runtime environment. But of course unless you're careful about what programs you give access to, it's very easy for someone to break out of (allow access to any interpreter such as perl or Python, and it's all over).

Another traditional solution typically involves chroot and/or carefully-chosen mount options. You can mount a filesystem noexec or nosuid, which inhibits these features. So by mounting any writable filesystem noexec, this will prevent the execution of any programs that aren't part of the read-only system. You can combine these to create a special chroot environment that closely controls what can be done.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.