The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

symlink protection and newer kernels (3.6+)

Discussion in 'Security' started by Spork Schivago, Jul 25, 2017.

  1. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    462
    Likes Received:
    52
    Trophy Points:
    28
    Location:
    corning, ny
    cPanel Access Level:
    Root Administrator
    So, I've been reading about the symlink kernel protection here: SecurityTeam/Roadmap/KernelHardening - Ubuntu Wiki

    And although I'm not running Ubuntu, I saw that the hardlink and softlink patches were accepted by upstream on 3.6. I'm now running kernel 4.9.36.

    I check /proc/sys/fs/protected_symlinks and /proc/sys/fs/protected_hardlinks and see that they're both set to 1. Would this mean I have symlink kernel protection and don't have to use Apache jails and mod_ruid2 or any other symlink race condition protection?

    I was just curious, because until I actually enabled the experimental Apache jail and mod_ruid2, the Security Advisor would warn me that I didn't have protection against the symlink race condition.

    Thanks!
     
  2. 24x7server

    24x7server Well-Known Member

    Joined:
    Apr 17, 2013
    Messages:
    1,393
    Likes Received:
    52
    Trophy Points:
    28
    Location:
    India
    cPanel Access Level:
    Root Administrator
    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.
     
    Spork Schivago likes this.
  3. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    36,980
    Likes Received:
    1,275
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Spork Schivago likes this.
  4. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    462
    Likes Received:
    52
    Trophy Points:
    28
    Location:
    corning, ny
    cPanel Access Level:
    Root Administrator
    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. :)
     
  5. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    36,980
    Likes Received:
    1,275
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    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.
     
    Spork Schivago likes this.
  6. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    462
    Likes Received:
    52
    Trophy Points:
    28
    Location:
    corning, ny
    cPanel Access Level:
    Root Administrator
    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.
     
    #6 Spork Schivago, Jul 26, 2017
    Last edited: Jul 26, 2017
    cPanelMichael likes this.
Loading...

Share This Page