Untitled

Story: Open source under attack?Total Replies: 17
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 privileges
Almost. 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!