Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I want to ensure no program can be run by a non-root user, where that user has the privilege to write. This also includes using "other" means of running a program with python, perl, bash which does not "respect" permission settings on files. Furthermore there should be no loopholes with using chmod or similar to escape. Is there an elegant solution with a vanilla Ubuntu 11.10 server?

share|improve this question

5 Answers 5

Give the user permissions to write to a directory which is on a volume mounted with the "noexec" mount option.

share|improve this answer
    
that would not solve the problem of a running with python, perl etc. –  user1005003 Mar 6 '12 at 13:35

This would be a real pig to do, and frankly goes against the purpose of giving shell access in the first place! Don't forget that in order to get to a shell, many programs are executed after the password is entered, least of which been BASH or similar to give you a console! If you don't want people executing programs, don't give them shell access. If all they need is to manage files, give them access to FTP/SFTP instead. You can even give access to SCP and just deny that user a shell in /etc/passwd (look at the deamon users)

share|improve this answer
    
The problem stems from program users which i wanted to ensure couldn't give access, download exploit and get control over the machine. –  user1005003 Mar 6 '12 at 13:25

No, there generally isn't. (The best is the noexec mounted directory, which doesn't prevent running perl/python scripts.) If they can execute chmod then they can make files put into their directory executable. To prevent this you need some kind of Rule Based Access Control, they are usually kernel modules. Since the Linux kernel has support for Security Modules most of these can be loaded and unloaded run-time.

Look into SELinux, which allows you to customize what programs (executable files) and-or users can do, though writing policies can be a bit tricky, but there are a lot of examples/references. (See http://oss.tresys.com/projects/slide )

GrSecurity has a global flag for TPE (trusted path execution), that means only root owned files can be run (and only from root owned directories), plus it also supports RBAC (rule based access control).

The general best practice is to set up a system, enable training mode for whichever LSM you've chosen, use it for a while, then lock it down, and let in the users. Then you fine-tune the restrictions when users encounter some problem. Of course just using the reference policies is a great starting point.

share|improve this answer
    
I am a bit surprised there is no easier way to protect your machine from users on it, i see quite a few "program xxx" has an bug which makes it write to somewhere it shouldn't, which leaves it open to upload root kit, and voila machine under someone else control. Just to make the last part more difficult i would prefer that the script kiddy runs into a problem of just downloading and running the root kit. –  user1005003 Mar 6 '12 at 13:32

You can prepare chroot jail and place there only that programs that you want your user to have access to (shell at least)

share|improve this answer

The following removes execute permissions on regular files, but keeps the execute permission for directories so they can be browsed...

chmod -R a-x+X directory

EDIT If you want the root user to still be able to execute, you can do the following..

su root
chmod -R g-x+X o-x+X directory
share|improve this answer
    
you would need to disown the user of the ownership over his dirs or else he would simply chmod it back. –  Hrvoje Špoljar Mar 6 '12 at 12:38
    
I think the question is not about the files owned/created by the non-root user... –  Mallik Mar 6 '12 at 12:48

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.