Linux Kernel 'proc' World Writeable File Security Bypass Vulnerability
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
View Poll Results: Do you think this is a security bug which needs fixing?
Linux Kernel 'proc' World Writeable File Security Bypass Vulnerability
At this point, there's still too much debate about this vulnerability for me to include it in the Kernel Vulns thread, even though it's now been issued a Bugtraq ID. Presumably, most of you keep an eye on Bugtraq (discussion has taken place on LKML too), so this issue wouldn't be news for you, but being able to discuss it in the comfort of LQ might be nice.
I'm really not invested in the argument one way or the other, but my take is: if you don't want a file to be written to, remove the write bit as appropriate.
That said, I could see how this idea would result in a blackhole of discussion.
I agree with Dan Yefimov, this is not a vulnerability, but a user error.
What exactly do you consider the user error to be? The assigning of world-writeable permissions to the file? The assumption that the file would be protected regardless by the restrictive permissions of the directory it resides in?
I found reading about this very interesting even if some of it is lost on me. Its odd why going though proc would bypass security on the file or am I missing something. Can you use other devices other then fd to accomplish this or is this specific to that?
What exactly do you consider the user error to be? The assigning of world-writeable permissions to the file? The assumption that the file would be protected regardless by the restrictive permissions of the directory it resides in?
Well, the main thing the author of this bug does not understand is that /proc or procfs is actually just a set of hard links, or acts like it.
If you do not set the permissions on a file itself correctly, not the directory above, then you cannot expect that you cannot read it. Also, like Dan says here: http://seclists.org/bugtraq/2009/Oct/291
what the author describes would not happen if the directory permissions were set correctly upon creation.
I can't say that I fully understand exactly what is going on, but it seems that this is no bug. It is that the user expects something that is not to be expected.
Whether this is actually a security hole--i.e. software behaving differently than specification--or simply a case of the user misunderstanding the specification, I think it should be "fixed," because it is a problem. I think the privilege level of a directory should represent the maximum privilege level of all contained files (and sub-folders). Either that, or creation of a new file should result in that file inheriting the read/write privileges of its parent, so that at least the parent's privileges becomes the default for all of the files within it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.