linux-kernel - Re: different capability from different namespace required for prctl_set_mm_exe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 26 Sep 2018 09:59:06 +0300
From:   Cyrill Gorcunov <gorcunov@...il.com>
To:     TongZhang <ztong@...edu>
Cc:     Greg KH <gregkh@...uxfoundation.org>, tglx@...utronix.de,
        akpm@...ux-foundation.org, linux@...inikbrodowski.net,
        ebiederm@...ssion.com, keescook@...omium.org, Dave.Martin@....com,
        wolffhardt.schwabe@....de, yang.shi@...ux.alibaba.com,
        LKML <linux-kernel@...r.kernel.org>, wenbo.s@...sung.com
Subject: Re: different capability from different namespace required for
 prctl_set_mm_exe_file

On Tue, Sep 25, 2018 at 07:37:14PM -0400, TongZhang wrote:
> I can see there are two problems,
> 
> First: In kernel/sys.c:2117  capable(CAP_SYS_RESOURCE), seems that ns_capable should
> be used to check capability against user namespace, instead of init_user_ns. Because a
> process in a user namespace may call prctl system call and this should be checked against
> their user namespace capability instead of init_user_ns capability.
> 
> Second: They should both require CAP_SYS_RESOURCE or CAP_SYS_ADMIN, is there any particular
> reasons for requiring different privilege?

Yes. We consider changing fields one by one in init_ns as an undesirable action,
mostly because some sysadmins/tools continue relay on this info for monitoring.
And requiring sysadmin here is too much: sysamin can do a way more than just
changing these members. In turn because userns is even more weak than init-ns
we require admin capability instead.

Again: non of the monitoring instrument should rely on the members this prctl
changes, they are not consistent and never was. But we still grip the privileges
here simply to not allow anyone change random members, at least in init-ns.

p.s. pleaase don't top post