On Fri, 2003-03-28 at 14:28, Martin Maney wrote:
> It was too late last evening when I was looking into this, and I don't
> have ready access to the system I'm doing the UML work on just now, but
> when I build it (2.4.20 w/the first (only, so far) UML patch), it seems
> to build a non-static binary. Was this what was being alluded to about
> SKAS and chroot not getting along, or have I just not noticed the "link
> statically" config setting?
Ahh. If you build a kernel without CONFIG_MODE_TT set, it builds a
dynamic binary by default, unless you also set CONFIG_STATIC_LINK.
As long as CONFIG_SKAS and CONFIG_TT (or CONFIG_SKAS and
CONFIG_STATIC_LINK) are set, you'll get a statically linked kernel.
> > The UML Kernel
> > Some filesystems
> Right, can't do without UML and its filesystems. Anything else here?
Well, for security, I do a couple of things:
1 - The jail isn't writable by the user. This prevents the the
UML user from creating files in its jail.
2 - The kernel and filesystems aren't _owned_ by the user, but
only group writable by it. This keeps the user from being able
to mess with the permissions of the filesystems, and prevents a
theoretical attack in which a user inside the UML could
overwrite a filesystem file with an evil program, break out of
UML, and execute it outside of the UML.
> > tmp/ (mount -t tmpfs -o size=$UML_MEM tmpfs $JAILDIR/tmp)
> What is this business about, anyway? I thought UML just plopped itself
> down in system memory and let the host OS worry about swapping.
UML uses a (memory-mapped?) file in /tmp for its RAM. I lock the size
of the tmp filesystem at $UML_MEM so that the UML user couldn't (again,
theoretically) create a file in there and execute it.
> > control/
> Why for?
This is where I have UML store its mconsole socket and it's pid.
Unfortunately, this directory must be writable by the UML user.
> > dev/net/tun (mknod $JAILDIR/dev/net/tun c 10 200)
> Is this needed when using static tuntap devices? I know only enough
> about tuntap so far to set one up for use with UML...so far.
Yeah. In order to bind to a tun device, a process needs to be able to
open this file. Once the UML's network interface is up, this file can
-- and probably should-- be removed; anyone who can write to this file
can create and destroy tun interfaces on the host at will.
This _does_ prevent the UML from being able to ifconfig down and
ifconfig up an interface, though, and thus, if you reboot the UML from
the inside, you'll lose networking. I haven't thought of a clean way