Re: Ports and privileges

["James W. Abendschan" <jwa () jammed com>]

On Wed, 25 Feb 1998 tqbf () secnet com wrote:
> > them for the past few months without problems, but I want to add "just 
> > one more" feature -- getting chroot() to fail if it's already chroot()ed --
> > before I make them available.
>
> Why would you want to do this? 

The idea is to jail your network daemons at boot time so even
if they are buggy and can be used to spawn a local shell,
the intruder is confined to the chrooted environment.

Since the "only" way to break out of a jail is to chroot()
back, why not make chroot() fail if it's already in jail?

All chroot-within-chroot attempts are logged with a rather
high priority, as it indicates likely intruder activity
on the firewall.

This isn't my original idea; I stole it from Marcus :-)

> From: "Marcus J. Ranum" <mjr () nfr net>
> To: firewall-wizards () nfr net
> Date: Sun, 21 Sep 1997 18:11:09 +0000
> Subject: Re: Here is my plan for firewall implementation
> X-mailer: Pegasus Mail for Win32 (v2.53/R1)

[ ... ]

> By sendmail on a hacked kernel I'm talking about
> things like running sendmail chrooted w/o privs and
> a configuration that doesn't have sendmail calling
> external mailers. Then all it has to do is fork itself
> off - at that point you can jigger the kernel to allow
> a specific UID (under which mail runs) to chroot,
> but you check so a chroot cannot be performed
> twice.* Also, wire the kernel so that the mail UID
> cannot call any of the exec( ) family.

[ ... ]

> (* add the following to vfs_syscalls.c in the chroot system
> call source:
>
> if (fdp->fd_rdir != NULL) {
>    log(LOG_ERR,"WARNING! chroot when already chrooted!");
>     /* return EPERM or whatever */
> }
> )

James

--
James W. Abendschan                              http://www.jammed.com
"'I think it looks like an anti-cyclone,' said Merlyn."  -- T.H. White