Skip to main content

symlink protection and newer kernels (3.6+)

Comments

5 comments

  • 24x7server
    Hi, If you have it on a kernel level, then it is good, however, what I think is it may also be necessary to have it enabled at an application level too. Apache would be the application layer and kernel will be at the core level.. Functioning of both of them may differ at some point.
    0
  • cPanelMichael
    Hello, The "fs.protected_hardlinks" and "fs.protected_symlinks" kernel options are not considered to be a kernel-level protection option for the symlink race condition as it pertains to Apache. You'd still need to use one of the options documented at: Symlink Race Condition Protection - EasyApache 4 - cPanel Documentation There's a feature request you may also find interest in at: cPanel Hardened Kernel for Centos 7.x - to prevent symlink attacks Thank you.
    0
  • Spork Schivago
    Thanks guys! Yeah, unfortunately, I realized the fs.protected_hardlinks and fs.protected_symlinks doesn't really fix the issue. It's just a bit of a work around and only works for sticky bit directories (like /tmp). With shell access, using a limited account, I was successfully able to modify a file in the /etc directory owned by root, which I didn't have write access to. I'm trying to find a free kernel level patch that I can apply to fix the symlink TOCTOU race condition, but I'm not really finding much. The GRSecurity patches cost money now, but I believe that's what the fs.protected_hardlinks / fs.protected_symlinks patch is based off of. I do have the Apache jail enabled with mod_ruid2, which I believe provides some sort of protection. I can also enable that Apache patch that's listed under Global Options, but I'm more interested at this point in trying to find a kernel level patch that fixes the problem permanently. I think because of how the kernel is written though, this might be hard. My understanding, it's just not Linux that suffers from this type of exploit, but a lot of *nix type operating systems and it's been around for a long time. If it was easy to fix, seeing how people have known about it for a long time now, I figure the Linux kernel would have been fixed a long time ago. The reason I'm looking for that kernel level patch is because even though mod_ruid2 is enabled and Apache jails, I was still successfully able to modify a file I wasn't supposed to be able to modify. I don't like that. Makes me feel something's wrong. :)
    0
  • cPanelMichael
    Hello, One other option to consider is to use the link traversal protection feature included with CloudLinux (if CloudLinux is an option): CloudLinux Documentation Thank you.
    0
  • Spork Schivago
    Yeah, that's what I want the most @cPanelMichael, but with the baby and the new house and all the bills, my wife says we just cannot afford it at this point in time. I think it's 14$ extra a month. But I'm getting ready to setup a development system at my house to work on cPanel plugins (I have some good ideas I think that you guys, along with some other people might find useful). The development system will be running CentOS, which is free, but I'll need to purchase another cPanel account I think, which costs money. I got the PC already, just need to wait until I can afford another license to start developing. I'd write the plugins and test them on my production server, but that's just a bad idea, using beta software on a production server. Anyway, my development system should match my production server, software wise at least. And if I have CloudLinux on my production server, I should have CloudLinux on my development server, which would be more money. I think they give a discount for 2+ licenses, but that 14$ would be more like 24$ a month for CloudLinux and then the extra 20$ for the extra cPanel license. It adds up real quick.
    0

Please sign in to leave a comment.