linux-kernel - Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs hidepid= field

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOWbf6cF23UGugNGb4wc9KNK7Yb4BG=V7yTnOP61+h2q5dA-nQ@mail.gmail.com>
Date:   Fri, 20 Jan 2017 16:56:24 +0100
From:   Lafcadio Wluiki <wluikil@...il.com>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     Djalal Harouni <tixxdz@...il.com>,
        Linux API <linux-api@...r.kernel.org>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs
 hidepid= field

On Thu, Jan 19, 2017 at 8:52 PM, Andy Lutomirski <luto@...capital.net> wrote:

>> Sure, the hidepid mount option is old enough, and this per-task
>> hidepid is clearly defined only for procfs and per task, we can't add
>> another switch that's relate to both a filesystem and pid namespaces,
>> it will be a bit complicated and not really useful for cases that are
>> in *same* pidns where *each* one have to mount its procfs, it will
>> propagate. Also as noted by Lafcadio, the gid thing is a bit hard to
>> use now.
>
> What I'm trying to say is that I want to understand a complete,
> real-world use case.  Adding a security-related per-task flag is can
> be quite messy and requires a lot of careful thought to get right, and
> I'd rather avoid it if at all possible.
>
> I'm imaging something like a new RestrictPidVisisbility= option in
> systemd.  I agree that this is currently a mess to do.  But maybe a

It's not just a "mess" to do, it's not possible afaics. The hidepid
thing is after all not really a mount option, but an option of the pid
namespace. Hence, if you want to restrict the visibility for one
service only, then you have to get your own PID namespace, but that
does a lot more than just hide visibility: it renumbers everything
after all...

> simpler solution would be to add a new mount option local_hidepid to
> procfs.  If you set that option, then it overrides hidepid for that
> instance.  Most of these semi-sandboxed daemon processes already have
> their own mount namespace, so the overhead should be minimal.

When I worked on the patches originally, I actually wanted to
implement this as true per-superblock procfs mount option. But this is
really hard to do, as the private superblock pointer of the procfs
instance currently points to the pid namespace, and breaking that up,
so that you can have multiple procfs superblocks per pid namespace is
a ton of work, and I doubt anyone would really like the complexity
this brings, just for adding a single 2bit option...

The per-process option is much simpler code-wise. It also has
semantical benefits: if the thing isn't a mount option it is
accessible with absolutely minimal privileges, as it does not imply
namespaces and mounting. This means, my Firefox can run with hidepid
turned on without my KDE Konsole instance also having to turn it on.
Or to say this differently: your suggested RestrictPidVisibility=
works nicely both for "systemd" as PID 1 and for "systemd --user" as
user "lafcadio", when it is per-process, but is much more complex to
implement if it was a true mount option.

L.