[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070926212408.6662231a@zoo.weinigel.se>
Date: Wed, 26 Sep 2007 21:24:08 +0200
From: Christer Weinigel <christer@...nigel.se>
To: David Newall <david@...idnewall.com>
Cc: Al Viro <viro@....linux.org.uk>, Phillip Susi <psusi@....rr.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Bill Davidsen <davidsen@....com>, majkls <majkls@...pere.com>,
bunk@...tum.de, linux-kernel@...r.kernel.org
Subject: Re: sys_chroot+sys_fchdir Fix
On Wed, 26 Sep 2007 20:04:14 +0930
David Newall <david@...idnewall.com> wrote:
> Al Viro wrote:
> > Oh, for fsck sake... Folks, it's standard-required behaviour.
> > Ability to chroot() implies the ability to break out of it. Could
> > we please add that (along with reference to SuS) to l-k FAQ and be
> > done with that nonsense?
>
> I'm pretty confident that it's only standard behavior for Linux.
> Every other unix says it's not allowed.
So how about reading up on the subject instead?
*spends five minutes with Google*
>From the OpenBSD FAQ (an operating system most know for being really,
really focused on security):
http://www.openbsd.org/faq/faq10.html
Any application which has to assume root privileges to operate is
pointless to attempt to chroot(2), as root can generally escape a
chroot(2).
Solaris:
http://www.softpanorama.org/Solaris/Security/solaris_privilege_sets.shtml
You must be root to make the chroot() call, and you should quickly
change to non-root (a root user can escape a chroot environment,
so if it's to be effective, you need to drop that privilege).
A chroot FAQ:
http://www.unixwiz.net/techtips/chroot-practices.html
There are well-known techniques used to escape from jail, but the
most common one requires root privileges inside the jail.
Another chroot FAT one linked to from the previous one:
http://www.bpfh.net/simes/computing/chroot-break.html
This page details how the chroot() system call can be used to
provide an additional layer of security when running untrusted
programs. It also details how this additional layer of security
can be circumvented.
Whilst chroot() is reasonably secure, a program can escape from
its trap.
Yet Another FAQ, this time about secure Unix Programming:
http://www.faqs.org/faqs/unix-faq/programmer/secure-programming/
chroot() only limits the file system scope and nothing else.
[further descriptions of how to break out of chroot, with and
without root privileges]
Convinced?
/Christer
--
"Just how much can I get away with and still go to heaven?"
Christer Weinigel <christer@...nigel.se> http://www.weinigel.se
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists