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.
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.
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.
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.
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?
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:
Oh well... --bind is still a fun option...
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.
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.
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.
don't forget to make sure /tmp /var/tmp and other user-writable dirs also are on the partitions mount with noexec flag.
Guess you can also use inotifywait with -r, -m and -e attrib options to reset -x flag if it is set by users
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.