Untitled
|
| Author | Content |
|---|---|
| Shagbag Jan 23, 2008 11:43 PM EDT |
Rootkit? It looks like someone forgot to chroot their Apache when they set it up. |
| tracyanne Jan 24, 2008 3:36 AM EDT |
All of them? |
| gus3 Jan 24, 2008 7:58 AM EDT |
chroot isn't a cure-all by a long shot. http://www.bpfh.net/simes/computing/chroot-break.html |
| tuxchick Jan 24, 2008 11:35 AM EDT |
chroot is not a security device. It's too bad it's taught that it is, because it never has been, and was never intended as such. |
| Shagbag Jan 24, 2008 12:07 PM EDT |
That's not what they say in the OpenBSD FAQ,tuxchick. Unless I'm mistaken chrooting apached is a key security precaution when running a web site. |
| Sander_Marechal Jan 24, 2008 1:05 PM EDT |
Shagbag: If you follow the article links to the various forum threads you can see it's a rootkit. A kernel module to be exact. The question is how they got the rootkit on the servers in the first place. |
| tuxchick Jan 24, 2008 1:54 PM EDT |
Shagbag, this is what Alan Cox says:Quoting: "chroot is not and never has been a security tool. People have built things based upon the properties of chroot but extended (BSD jails, Linux vserver) but they are quite different."http://kerneltrap.org/Linux/Abusing_chroot info chroot says nothing about using it as a security device: http://www.cs.vassar.edu/cgi-bin/info.cgi?(coreutils)chroot+invocation You need root privs to rootkit anything, so once you have that, game over, chroot or no. |
| Shagbag Jan 24, 2008 2:17 PM EDT |
Thanks for clearing that up for me, tuxchick. I see your point about rootkit having root privileges ergo it can chroot itself out of any 'jail'.
This is the OpenBSD FAQ I was talking about: 10.16 - Tell me about this chroot(2) Apache? In OpenBSD, the Apache httpd(8) server has been chroot(2)ed by default. While this is a tremendous boost to security, it can create issues, if you are not prepared. What is a chroot? A chroot(2)ed application is locked into a particular directory and unable to wander around the rest of the directory tree, and sees that directory as its "/" (root) directory. In the case of httpd(8), the program starts, opens its log files, binds to its TCP ports (though, it doesn't accept data yet), and reads its configuration. Next, it locks itself into /var/www and drops privileges, then starts to accept requests. This means all files served and used by Apache must be in the /var/www directory. In the default configuration of OpenBSD, all the files in the /var/www directory are read-only by the user Apache runs as, http://www. This helps security tremendously -- should there be a security issue with Apache, the damage will be confined to a single directory with only "read only" permissions and no resources to cause mischief with. |
| tuxchick Jan 24, 2008 2:54 PM EDT |
hmm, that sounds pretty ingenious. Rather like how SELinux and AppArmor are supposed to work. I wonder if it works the same way on Linux? Trying to get details on the actual exploit is frustrating. I haven't found a single bit of concrete information yet, just a lot of vague scary stuff. |
| Shagbag Jan 25, 2008 5:09 AM EDT |
FreeBSD has a similar concept call 'Jails': http://www.freebsd.org/doc/en/books/handbook/jails.html Is there not the same facility in linux? |
| Abe Jan 25, 2008 6:20 AM EDT |
Quoting:should there be a security issue with Apache, the damage will be confined to a single directory with only "read only" permissions and no resources to cause mischief with.Isn't this the same as ACL (Access Control Lists)? As I recall, there was a security feature in VMS where certain privileges are granted to the application instead of the user account using ACL, sort of like the S (sticky) bit in Linux. I am not sure but, isn't that the same? |
| NoDough Jan 25, 2008 6:48 AM EDT |
Access Control Lists are a much more generic concept and basically a replacement for the User|Group|World permissions. They control user or process access to a single file, folder, or directory object (i.e. LDAP.) ACLs, however, do not hamper a user from seeing any part of the file system to which they have permissions. A chroot or jail, OTOH, makes a sizable chunk of the file system disappear. |
| Abe Jan 25, 2008 7:57 AM EDT |
Quoting:Access Control Lists are a much more generic concept and basically a replacement for the User|Group|World permissions. ...@NoDough, I believe an ACL doesn't replace User|Group|World permissions, it simply amends them for designated objects that carry the ACL. I think I know what ACL is and does, I was referring more to the s-sticky bit in Linux, which grants the user process specific privileges to the relevant object carrying the s-bit even if the user account doesn't have them. No password is required. VMS has the same permission feature where privileges are passed on to the user by the application while running and from within the application only. Those permissions are granted/restricted by a VMS ACL that the application has. Just like sudo in Linux and "Run As" application in Windows. But these are interactive and have to enter a password. A chroot or jail are global, just like "Run As" administrator shell in Windows. Then again, It might have been wishful thinking on my part and misunderstood their features. |
| gus3 Jan 25, 2008 8:16 AM EDT |
@Abe: Are you sure you aren't thinking of SUID/SGID? |
| NoDough Jan 25, 2008 8:51 AM EDT |
Abe, I can't speak to VMS. Don't know anything about it. However, I'm certain that chroot and jail are not just like "Run As" in Windows. |
| Abe Jan 25, 2008 10:28 AM EDT |
Quoting:Are you sure you aren't thinking of SUID/SGID?You are right Gus3, I confused the t & s bits. it was setuid & setgid that I was trying to point to. T-bit - to pass on inheritance of directory permissions http://en.wikipedia.org/wiki/Sticky_bit S-Bit - to assign elevated privileges http://en.wikipedia.org/wiki/Setuid |
| gus3 Jan 25, 2008 8:34 PM EDT |
Quoting:S-Bit - to assign elevated privilegesAlmost. It assigns alternate privileges, which may or may not be root. It can also be used to reduce privileges. |
| Abe Jan 26, 2008 7:43 AM EDT |
Quoting:Almost. It assigns alternate privileges, which may or may not be root. It can also be used to reduce privileges. Gus3, Are we nitpicking here! :) No seriously, although I appreciate your feedback, my first post was in response to the question whether Linux has a feature to set permissions that would secure/protect objects similar to BSD, not to write full documentation of it. Eventually, it reached to a combination of 3 different methods that you can use to accomplish what is needed. All three can be used and depends which supplements/overrides the others. That depends on the sequence the OS processes them and which overrides the others to create a composite security of all. Disclaimer: For those who decide to use them, they should better make sure to know their details by referencing the documentation, test them to make sure they work the way they intend them to, before they implement them. They shouldn't take my general description as facts because I did create them and I am not an expert either. If you notice in my previous posts, I do use amend, restrict, grant access in various places. In the last post, I was just using the same terminology used by Wikipedia, which I linked to. To come to think about it, although you are technically correct, the S-Bit is mainly/primarily used to grant not restrict. If you were to restrict, you are better off to use G/UID permissions instead. It is simpler and more clear. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!