Hi all,
I've stumbled onto what seems to have broken somewhere between 2.4.8 and
2.4.18 (sorry, I've been unable to test it on a later version just yet).
Basically, when using chroot(), syslog() calls don't work.
The following simple example is broken on 2.4.18:
#include <stdio.h>
#include <sys/syslog.h>
int main(void) {
chroot("/home/steve");
syslog(LOG_ALERT, "TEST");
}
An strace reveals the following:
connect(3, {sin_family=AF_UNIX, path="/dev/log"}, 16) = -1 ENOENT (No such
file or directory)
Is this intentional? If so, is there a work-around? I discovered this when
debugging 'rwhod', but I imagine there are many more utils that would be
affected too.
Cheers,
Steve Micallef
> connect(3, {sin_family=AF_UNIX, path="/dev/log"}, 16) = -1 ENOENT (No such
> file or directory)
>
> Is this intentional? If so, is there a work-around? I discovered this when
> debugging 'rwhod', but I imagine there are many more utils that would be
> affected too.
I don't know how it ever did work, if in fact it did for you. /dev/log
is not a kernel device, it's just a normal socket created by syslogd.
Now, if you use devfs, and mount devfs under the chroot, it magically
propogates /dev/log. But that's not the normal thing.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/
You're right - my mistake, it doesn't actually work on 2.4.8 either, I think
I was looking at the wrong thing when I thought it was actually working.
Is it worth considering (optionally) making /dev available to chroot()'ed
environments, or would that just defeat the whole purpose of chroot()?
Regards,
Steve.
> -----Original Message-----
> From: Ben Collins [mailto:[email protected]]
> Sent: Monday, 4 August 2003 3:19 PM
> To: Steven Micallef
> Cc: '[email protected]'
> Subject: Re: chroot() breaks syslog() ?
>
>
> > connect(3, {sin_family=AF_UNIX, path="/dev/log"}, 16) = -1
> ENOENT (No such
> > file or directory)
> >
> > Is this intentional? If so, is there a work-around? I
> discovered this when
> > debugging 'rwhod', but I imagine there are many more utils
> that would be
> > affected too.
>
> I don't know how it ever did work, if in fact it did for you. /dev/log
> is not a kernel device, it's just a normal socket created by syslogd.
>
> Now, if you use devfs, and mount devfs under the chroot, it magically
> propogates /dev/log. But that's not the normal thing.
>
> --
> Debian - http://www.debian.org/
> Linux 1394 - http://www.linux1394.org/
> Subversion - http://subversion.tigris.org/
> WatchGuard - http://www.watchguard.com/
> __________ Information from NOD32 1.449 (20030630) __________
>
> This message was checked by NOD32 for Exchange e-mail monitor.
> http://www.nod32.com
>
>
>
>
On Mon, Aug 04, 2003 at 03:49:48PM +1000, Steven Micallef wrote:
> You're right - my mistake, it doesn't actually work on 2.4.8 either, I think
> I was looking at the wrong thing when I thought it was actually working.
>
> Is it worth considering (optionally) making /dev available to chroot()'ed
> environments, or would that just defeat the whole purpose of chroot()?
Enable devfs, and you can mount devfs anywhere, even in chroots, and it
will propogate things like /dev/log.
Generally chroot environments don't want that though.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/
if you need any devices in /dev after the chroot you can create anything
you need in the appropriate directory.
with syslog you need to look at the -a option to syslogd to make things
work the way you want them to.
David Lang
On Mon, 4 Aug 2003, Ben Collins wrote:
> Date: Mon, 4 Aug 2003 01:34:38 -0400
> From: Ben Collins <[email protected]>
> To: Steven Micallef <[email protected]>
> Cc: "'[email protected]'" <[email protected]>
> Subject: Re: chroot() breaks syslog() ?
>
> On Mon, Aug 04, 2003 at 03:49:48PM +1000, Steven Micallef wrote:
> > You're right - my mistake, it doesn't actually work on 2.4.8 either, I think
> > I was looking at the wrong thing when I thought it was actually working.
> >
> > Is it worth considering (optionally) making /dev available to chroot()'ed
> > environments, or would that just defeat the whole purpose of chroot()?
>
> Enable devfs, and you can mount devfs anywhere, even in chroots, and it
> will propogate things like /dev/log.
>
> Generally chroot environments don't want that though.
>
> --
> Debian - http://www.debian.org/
> Linux 1394 - http://www.linux1394.org/
> Subversion - http://subversion.tigris.org/
> WatchGuard - http://www.watchguard.com/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 04 August 2003 07:27, Steven Micallef wrote:
> Hi all,
>
> I've stumbled onto what seems to have broken somewhere between 2.4.8 and
> 2.4.18 (sorry, I've been unable to test it on a later version just yet).
> Basically, when using chroot(), syslog() calls don't work.
>
> The following simple example is broken on 2.4.18:
>
> #include <stdio.h>
> #include <sys/syslog.h>
>
> int main(void) {
> chroot("/home/steve");
> syslog(LOG_ALERT, "TEST");
> }
consider syslogd's -a option. Or simply call openlog(3) with LOG_NDELAY before
chroot(). Or place the first call to syslog() before chroot(). Syscall() does
not close the socket between calls.
int main(void) {
openlog( "klaus", LOG_NDELAY, LOG_NEWS);
chroot("/tmp");
printf( "before\n" ); fflush( stdout );
syslog(LOG_ALERT, "TEST1");
printf( "between\n" ); fflush( stdout );
syslog(LOG_ALERT, "TEST2");
}
strace give the following output:
...
socket(PF_UNIX, SOCK_DGRAM, 0) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
connect(3, {sin_family=AF_UNIX, path="/dev/log"}, 16) = 0
chroot("/tmp") = 0
...
write(1, "before\n", 7before
) = 7
...
send(3, "<57>Aug 4 07:17:09 klaus: TEST1", 32, 0) = 32
rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
write(1, "between\n", 8between
) = 8
...
send(3, "<57>Aug 4 07:17:09 klaus: TEST2", 32, 0) = 32
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/LgoGwicyCTir8T4RAqbzAJ9SPwFSnLyinG0C+ya/uTJRR4vwGQCeLxiV
ilmX6A7oJjou6ympLhFsDC4=
=mfSg
-----END PGP SIGNATURE-----
> consider syslogd's -a option. Or simply call openlog(3) with
> LOG_NDELAY before
> chroot(). Or place the first call to syslog() before
> chroot(). Syscall() does
> not close the socket between calls.
>
> int main(void) {
> openlog( "klaus", LOG_NDELAY, LOG_NEWS);
> chroot("/tmp");
> printf( "before\n" ); fflush( stdout );
> syslog(LOG_ALERT, "TEST1");
> printf( "between\n" ); fflush( stdout );
> syslog(LOG_ALERT, "TEST2");
> }
That works perfectly, thanks.
Regards,
Steve.
Previously Ben Collins wrote:
> Enable devfs, and you can mount devfs anywhere, even in chroots, and it
> will propogate things like /dev/log.
Why not use a bind mount instead of forcing devfs on him?
Wichert.
--
Wichert Akkerman <[email protected]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
On Mon, Aug 04, 2003 at 03:49:48PM +1000, Steven Micallef wrote:
> You're right - my mistake, it doesn't actually work on 2.4.8 either, I think
> I was looking at the wrong thing when I thought it was actually working.
>
> Is it worth considering (optionally) making /dev available to chroot()'ed
> environments, or would that just defeat the whole purpose of chroot()?
IMHO, devfs in chroot environment, is defeating the purpose
because if you have access to raw devices, like the device
your chroot dir is on, you can easily mount that device
again, and voila you have access to the full tree, if you
just have access to, lets say a ramdisk (as raw device of
course), you can also easily write on it, and create the
required device nodes yourself, then mount, and again
everything is available ...
best thing to do is to copy only those devices, which are
absolutely required to the chrooted environment ...
HTH,
Herbert
> Regards,
>
> Steve.
>
> > -----Original Message-----
> > From: Ben Collins [mailto:[email protected]]
> > Sent: Monday, 4 August 2003 3:19 PM
> > To: Steven Micallef
> > Cc: '[email protected]'
> > Subject: Re: chroot() breaks syslog() ?
> >
> >
> > > connect(3, {sin_family=AF_UNIX, path="/dev/log"}, 16) = -1
> > ENOENT (No such
> > > file or directory)
> > >
> > > Is this intentional? If so, is there a work-around? I
> > discovered this when
> > > debugging 'rwhod', but I imagine there are many more utils
> > that would be
> > > affected too.
> >
> > I don't know how it ever did work, if in fact it did for you. /dev/log
> > is not a kernel device, it's just a normal socket created by syslogd.
> >
> > Now, if you use devfs, and mount devfs under the chroot, it magically
> > propogates /dev/log. But that's not the normal thing.
> >
> > --
> > Debian - http://www.debian.org/
> > Linux 1394 - http://www.linux1394.org/
> > Subversion - http://subversion.tigris.org/
> > WatchGuard - http://www.watchguard.com/
> > __________ Information from NOD32 1.449 (20030630) __________
> >
> > This message was checked by NOD32 for Exchange e-mail monitor.
> > http://www.nod32.com
> >
> >
> >
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
> IMHO, devfs in chroot environment, is defeating the purpose
> because if you have access to raw devices, like the device
> your chroot dir is on, you can easily mount that device
> again, and voila you have access to the full tree, if you
You need to be root to mount the device, and as root you can also create
the device special file. A chroot environment does not reliably guard
against root breaking out of it.
Olaf
> > IMHO, devfs in chroot environment, is defeating the purpose
> > because if you have access to raw devices, like the device
> > your chroot dir is on,
> > you can easily mount that device again, and voila you have
> > access to
> > the full tree, if you
>
> You need to be root to mount the device, and as root you can
> also create the device special file. A chroot environment
> does not reliably guard against root breaking out of it.
That's not completly wrong nor is it completly true. :)
You _CAN_ guard yourself from root's breaking out of some chroot environment.
Using grsec (http://www.grsecurity.net). Denying double-chroots, creation of special
files within chroot-environments and if you like it... Deny mounting within
chroot. :)
There are many options provided - just use 'em. :)
Best regards,
Oliver
On Wed, Aug 06, 2003 at 10:42:40AM +0200, Oliver Pitzeier wrote:
> > > IMHO, devfs in chroot environment, is defeating the purpose
> > > because if you have access to raw devices, like the device
> > > your chroot dir is on,
> > > you can easily mount that device again, and voila you have
> > > access to
> > > the full tree, if you
> >
> > You need to be root to mount the device, and as root you can
> > also create the device special file. A chroot environment
> > does not reliably guard against root breaking out of it.
>
> That's not completly wrong nor is it completly true. :)
>
> You _CAN_ guard yourself from root's breaking out of some chroot environment.
> Using grsec (http://www.grsecurity.net). Denying double-chroots, creation of special
> files within chroot-environments and if you like it... Deny mounting within
> chroot. :)
hmm, how will you avoid creation of special (devicenodes)
files if I have raw access to any partition? I can 'simply'
use xxd to create my special inodes on the medium ...
and I would not care if mount is enabled or not when I
wipe the root partition with dd ...
best,
Herbert
> There are many options provided - just use 'em. :)
>
> Best regards,
> Oliver
Herbert P?tzl <[email protected]> wrote:
[ ... ]
> hmm, how will you avoid creation of special (devicenodes)
> files if I have raw access to any partition? I can 'simply'
> use xxd to create my special inodes on the medium ...
> and I would not care if mount is enabled or not when I
> wipe the root partition with dd ...
AFAIK, there are possibilities to deny _RAW_ access to partitions, while in a chroot-jail... If not, I'll tell the grsec-team to implement a new feature. :)
Best regards,
Oliver