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

I want to ensure that users of my system are incapable of chmodding files +x, and I do not want anything in /home/ or /var/ to be executable.

I can't put them on separate partitions.

Running Ubuntu 9.04 Server.

share|improve this question
3  
Got to ask, 'why?'. Seems an odd restriction to me and there might be a different way of approaching the problem. –  CK. Jun 1 '09 at 14:05
1  
I agree - what's the point of restricting the hell out of users? I know a shell account provider, rootshell.be, that has a lot of such "security" - and it's still possible to get around. –  grawity Jun 1 '09 at 18:08
add comment

6 Answers

up vote 11 down vote accepted

I was going to suggest a wrapper to chmod or something, but the more I think about it, the users will eventually find a way around this (scp an executable from another box, or run perl -s "chmod('FILE');", etc...

So, I think the FS method is the best. Since you say you can't move them to a new file system, what about using a --bind mount to "remount" /home and /var without exec privileges?

mount -o noexec --bind /var /var
mount -o noexec --bind /home /home

I'm not sure if that would work or not, but seems promising...

EDIT:
Well, I like my nice, shiny "nice answer" badge from this answer, but after playing with it I don't think it will work. My original test was on an old (2.4.9) kernel, and the "mount on top of itself" functionality appeared to work. I tried it again with a newer kernel (2.6.18) and it does not appear to work. I started to look at work arounds (like renaming /var and /home to something else and then mounting them back. I didn't get very far though because I found this in the man page for mount on the newer box:

Note that the filesystem mount options will remain the same as those on the original mount point, and cannot be changed by passing the -o option along with --bind/--rbind.

Oh well... --bind is still a fun option...

share|improve this answer
1  
I feel like there would be problems attempting to bind mount a partition over itself. I would recommend pretty dang thorough testing before rolling this out into production. –  Scott Pack Jun 1 '09 at 15:03
    
Modify /etc/fstab and add noexec to the options field so noexec is used every time the machine starts and the filesystem is mounted. –  Garry Harthill Jun 1 '09 at 15:27
    
Did this actually work? The answer seems to indicate that it might work. Has anyone confirmed? –  pcapademic Jun 1 '09 at 23:26
add comment

I can think of 2 ways of doing this, one dirty, and one good. Let's start with the dirty.

Write a shell script that runs very regularly as a cronjob, say every 5 or 10 minutes. It would explicitly remove the exec flag from all files in those two directories, i.e.

chmod -R ugo-x /home /var

The better way is to do it at the filesystem level. Create new partitions to house both var and home, this is considered best practice anyway. Then add the ‘noexec’ option to mount. This will prevent, at the filesystem level, the execution of files stored within those directories.

share|improve this answer
add comment

This is a perfect example of the kind of question that should be answered thusly:

You seem to have come up with a solution for a complex problem, and are now asking specific questions on how to implement this solution. Could you please instead describe the original problem you are trying to solve?

My experience is that it's pretty important for a sysadmin to know when to respond to a request with "what? why?". How important depends on the propensity of the users to describe their original problem or to attempt to come up with their own solutions and ask for assistance in implementing them. In certain environments, it's the difference between expensive catastrophically bad solutions, and cheap good solutions.

share|improve this answer
add comment

don't forget to make sure /tmp /var/tmp and other user-writable dirs also are on the partitions mount with noexec flag.

share|improve this answer
add comment

Guess you can also use inotifywait with -r, -m and -e attrib options to reset -x flag if it is set by users

share|improve this answer
add comment

Sounds like you have a policy problem...
... and presumably this was caused by a real problem vs you being paranoid.
Aren't you limiting the effectiveness of the computing platform by doing this?

many scripts can be run by simply invoking the interpreter directly:
sh ./mybashscript.sh
perl ./myperldaemon.pl

So presumably you are trying to prevent a native executable from running?

Best to deal with this problem via policy and policing/auditing...
at best, you'll only keep the less experienced users at bay anyway.

share|improve this answer
    
you can run dynamically linked native executables even if they are not executable, by invoking /lib/ld-linux.so with the right parameters. This is not a bug, but a feature, so that you can call for example ln -s (which is dynamically linked) to link /lib-foo to /lib, while ln -s cannot find the libc (because it is in /lib-foo and not in /lib). –  mihi Jun 1 '09 at 21:26
add comment

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.