Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

CloudLinux busted — twice

Posted Jul 8, 2012 18:42 UTC (Sun) by cloudlinux (subscriber, #81222)
In reply to: CloudLinux busted — twice by spender
Parent article: CloudLinux busted — twice

Brad,

Did you do the check on open or on creation of the symlink?
We explored both ways -- and rejected them.
If you are doing check on open -- it must carry a price tag. On a shared hosting server, open is pretty common operation, and you just made it costly.
Also, to properly defend against race conditions it has to be atomic, which makes it even costlier.
We really didn't want to make performance worse, if we didn't have to.

If you did it on creation of symlink (we actually know about hosting company who did it that way) -- it wouldn't work for us as well, as it breaks some installation scripts, like WHMSonic ShoutCast Admin Pro (the script makes a link as a user, for each user, to sc_serv binary that is owned by root). I was pretty sure there other apps like that - and I didn't want to deal with all the support questions.

Or am I missing something?

(Log in to post comments)

CloudLinux busted — twice

Posted Jul 8, 2012 20:56 UTC (Sun) by spender (subscriber, #23067) [Link]

It's on following of a symlink and only involves a simple uid check, no rebuilding of paths or anything else that would have to be done via a module hack. It's even simpler and less "expensive" than the symlink restrictions in grsecurity (that have been copied upstream). It does not impact performance at all. It doesn't have to use atomic operations (if that's what you're implying) -- it simply has to check the same inodes the kernel resolves when following a link.

-Brad

CloudLinux busted — twice

Posted Jul 8, 2012 21:16 UTC (Sun) by spender (subscriber, #23067) [Link]

BTW the mention of "open" or "create" as the check points is troubling. Path walking code is used by many more areas of the kernel than just through the "open" syscall. I'm making a prediction here, but it sounds like maybe you created a module that hooked a syscall and as a result it was slow and in fact just reproduced the same userland race (and made it even worse).

By hooking "open" you would have performed the same copying from userland of the opened filename (or maybe just accessed it directly!), then probably did an lstat and stat from the kernel against the same name (with the associated slowness and race). This would have introduced an additional race: the attacker wouldn't have to touch the filesystem to exploit a race, but could just replace the filename string with a different one between when your "open" hook and the real kernel's "open" executed.

Like I said, this is a feature that needs to be implemented deep in VFS internals to be correct -- a closed-source implementation will either be weaker or introduce additional races.

This is the patch:
http://grsecurity.net/~spender/symlinkown.diff

-Brad

CloudLinux busted — twice

Posted Jul 9, 2012 14:50 UTC (Mon) by cloudlinux (subscriber, #81222) [Link]

Brad,

We patch a lot in the kernel, and it really doesn't matter for us open source / closed source for most of the minor things.

I guess if it is portable to 2.6.18 kernel as well, and we can port kernel changes to prevent creation of hard links to files owned by someone else to that kernel -- it might work for us.

What I would need to research first though -- if any control panel installs symbolic links to files owned by root into virtual hosts that are not for end user (like for webmail, etc...). If they do -- this solution would break it.

Anyway -- it does look very good, thank you!