[Cialug] CAP_SYS_CHROOT

Shane Nehring shane at ntoast.com
Wed Mar 9 16:59:22 UTC 2022


I guess, more correctly, it allows you to use setns to change mount
namespaces. Which makes sense to bundle with chroot.

On Wed, Mar 9, 2022 at 10:57 AM Shane Nehring <shane at ntoast.com> wrote:

> I think the whole idea behind the capabilities is granular permissions
> control, with the idea that you give an application the absolute least
> permissions it needs to run and nothing more, ideally to reduce your attack
> surface.
>
> Per the capabilities man page CAP_SYS_CHROOT also controls the ability to
> use setns. I know setns is used in a lot of container escape stuff
> (unsurprisingly), and I wouldn't be surprised if there were a few
> historical exploits that've used chroot. setns could conceivably be used
> for privilege escalation if there were some bug that allowed moving into a
> higher privileged namespace that was also exploited.
>
> On Wed, Mar 9, 2022 at 10:14 AM Todd Walton <tdwalton at gmail.com> wrote:
>
>> Are there any security implications of giving a process the CAP_SYS_CHROOT
>> capability? It seems like CAP_SYS_CHROOT's very existence would imply that
>> the kernel developers consider it something you might *not* want to grant.
>> But surely a process using chroot could only result in it having the same
>> or fewer permissions/privileges. Never more.
>>
>> I understand the argument that "chroot is not a security feature". Yes,
>> yes. But it couldn't make things worse, could it? In what situations would
>> I *not* want to grant CAP_SYS_CHROOT?
>>
>> --
>> Todd
>> _______________________________________________
>> Cialug mailing list
>> Cialug at cialug.org
>> https://www.cialug.org/cgi-bin/mailman/listinfo/cialug
>>
>


More information about the Cialug mailing list