There is a host with a local service that receives data from a remote location (via e.g. http) and saves it locally under /var/log/data/ in some mydir.

$ ls -al /var/log/data  
drwxr-sr-x+ 4 root datalog                4096 Feb  4 18:59 .  
drwxr-xr-x  4 root root                   4096 Feb  4 18:59 ..  
drwxr-sr-x+ 2 root service                4096 Feb  4 19:07 mydir  

The local service is run with service:service ownership.

Let's assume that I want to prevent execution of an exploit program that would be found in /var/log/data/mydir:

-rwxr-sr-x 1 root service 133156 Jul 19  2014 exploit  

Note the "s" (setgid) bit on exploit file, which makes it execute with service group rights (the same as the local service).

How can I prevent potential exploit from being executed there ?
Removing "x" (go-x) from /var/log/data/ and /var/log/data/mydir ? It would probably disrupt service's work ... ?
Any other idea ?

  • 1
    remount /var with noexec flag
    – Darek
    Feb 18 '15 at 13:07

As i can see there is no write permission to group & others, So they cant create any file/directory here.

you just need to make sure that if you remove write permission from root, what will happen?

  • Read the first sentence of the question. If an attacker can take control of the remote server, he can get his content to be downloaded to the OP's machine.
    – Scott
    Feb 18 '15 at 19:45

You can use an ACL to deny all users write and execute permissions and then explicitly allow only the service account user to only have the full rwx. http://linux.die.net/man/1/setfacl


You can reduce the risk of a persistent exploit by making sure that the service is not able to create an executable file anywhere. For that, make sure that all the filesystems that the service can access meet at least one of the following conditions:

  • mounted read-only
  • mounted with the noexec option
  • contains no directory that is writable by the service

Running the service in a chroot jail will help with reducing the part of the filesystem that the service can see at all. You can use bind mounts to make a view of a part of the filesystem at a different location.

Note that setgid is mostly a red herring here. If the attacker can create an executable file and can trick your service into running it, the exploit will be running with the service's group anyway. Setgid is only an issue if the attacker can create an executable, setgid file through your service and can trick another user into executing the file.

Also note that you only get a very small amount of protection this way. If the attacker can trick your system into executing the file that they've uploaded, chances are that they already have a way to execute arbitrary code. One thing that you may gain is that if the attacker is prevented from writing an executable file, the exploit might not survive a restart of the service. However this assumes that the exploit vector is e.g. some networking vulnerability, and not e.g. a vulnerability in file parsing.

An alternative approach to confine your service is to use a security framework such as SELinux. Writing a policy can be hard work but you have more control.

  • There could be multiple local services run simultaneously on the host. Each local service may receive data from multiple remote sources simultaneously, resulting in multiple connections. It is also possible to run an equivalent of the service manually - the executable would be run with root:root ownership or service:service if chown-ed. Other users/entries can work with files in those log dirs too (those files have binary format and will be interpreted for merge, cross-reference, or display). So, there are chances that various users/processes could be exposed to that setgid exploit.
    – user103573
    Feb 19 '15 at 11:52
  • Each local service may specify its own "mydir" or share it. Regarding the setgid on dirs, /var/log/data/mydir in particular - is it not aiding the attacker's exploit in acquiring service gid automatically ? Is the setgid on dir a means of obfuscation here ? In our case only local service(s) are supposed to create and fill in the log dirs. The setgid on dir makes sense only if the dir is shared by users with different gid's (e.g. shared project dir). If so, would it be preferable to remove the setgid on dir if possible in this service and fs layout configuration ?
    – user103573
    Feb 19 '15 at 11:55
  • @user103573 I'm not sure whether the setgid attribute on the directory is useful, it depends on more details of your architecture than can fit in a comment. Feb 19 '15 at 12:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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