Re: Offhand question - improving chroot

Dale Pontius <dale@edgehp.invalid> wrote:
> It's well-known that root can break out of chroot rather easily.

> Using capabilities there's a fair amount being done to elevate what
> non-root processes can do, and avoid using root. But at the moment
> most of this is non-standard, sometimes significantly so.

> What about going the opposite direction, and in the chroot wrapper
> use something like execcap to remove root's capabilities? As an
> alternative to elevating select capabilities of a user process, how
> about stripping most capabilities from a root process?

Actually things like SELinux, LIDS, and grsecurity do exactly this
--- limit what root can do (requiring levels of authentication/authorization
beyond just UID==0)

Even just the /proc/sys/kernel/cap-bound sysctl mechanism can be
used in a minimal way to do some of this (system-wide) and libcap
utilities can restrict (or selectively elevate) them by process/family.

http://www.kernel.org/pub/linux/libs...y/linux-privs/

For some ugly little README files on the capabilities.

> For instance, after executing the chroot call, remove at least the
> chroot capability, so it can't use that escape. It would make sense
> to remove most other capabilities, as well.

Look at libcap (not libpcap; which is for tcpdump --- promiscuous mode
capabilities).

> Perhaps this seems like it's doing the same thing as elevating
> select user capabilities, but it should be doable with just libpcap,
> and no non-standard kernel posix inheritability patches.

I think you mean libcap, not libpcap.

> Dale Pontius

Some people are working on it. I think the most mature work has been
done in LIDS which builds over the top of the libcap and capabilities
and then adds considerably more.

--
Jim Dennis,
Starshine: Signed, Sealed, Delivered

James T. Dennis wrote:
> Dale Pontius <dale@edgehp.invalid> wrote:
>
>>It's well-known that root can break out of chroot rather easily.
>
>
>>Using capabilities there's a fair amount being done to elevate what
>>non-root processes can do, and avoid using root. But at the moment
>>most of this is non-standard, sometimes significantly so.
>
>
>>What about going the opposite direction, and in the chroot wrapper
>>use something like execcap to remove root's capabilities? As an
>>alternative to elevating select capabilities of a user process, how
>>about stripping most capabilities from a root process?
>
>
> Actually things like SELinux, LIDS, and grsecurity do exactly this
> --- limit what root can do (requiring levels of authentication/authorization
> beyond just UID==0)
>
I've looked a bit at all of these.
SELinux looks most potent, but looks more like 'pick up and study for a
while, then use' as opposed to 'pick up and use'.
I tried LIDS once, but the machine I want to protect doesn't have
development tools. From what I could tell, LIDS wants to be built on the
target machine. I tried build-move-install, but things started getting
glitchy soon enough that I could stop without damage.
I've looked at GRSecurity a little, and it might be my best bet, for now.

For this question, I was just being more limited and abstract...

By reducing root capabilities with execcap, is it possible to make a
chroot jail unbreakable.

I was just wondering about the one simple tool.

> Even just the /proc/sys/kernel/cap-bound sysctl mechanism can be
> used in a minimal way to do some of this (system-wide) and libcap
> utilities can restrict (or selectively elevate) them by process/family.
>
> http://www.kernel.org/pub/linux/libs...y/linux-privs/
>
> For some ugly little README files on the capabilities.
>
I do this today. Makes for a system that needs reboot for ANY
maintenance, including log rotation.
>
>>For instance, after executing the chroot call, remove at least the
>>chroot capability, so it can't use that escape. It would make sense
>>to remove most other capabilities, as well.
>
>
> Look at libcap (not libpcap; which is for tcpdump --- promiscuous mode
> capabilities).
>
Oops. I would have figured it out, eventually.
>
>>Perhaps this seems like it's doing the same thing as elevating
>>select user capabilities, but it should be doable with just libpcap,
>>and no non-standard kernel posix inheritability patches.
>
>
> I think you mean libcap, not libpcap.
>
>
>>Dale Pontius
>
>
> Some people are working on it. I think the most mature work has been
> done in LIDS which builds over the top of the libcap and capabilities
> and then adds considerably more.
>
Thanks,
Dale