linux-kernel - Re: [PATCH 0/2 v2] userns: show current values of user namespace counters

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:   Mon, 10 Oct 2016 15:44:09 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Andrei Vagin <avagin@...tuozzo.com>
Cc:     <avagin@...nvz.org>, <containers@...ts.linux-foundation.org>,
        <linux-kernel@...r.kernel.org>,
        Serge Hallyn <serge.hallyn@...onical.com>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 0/2 v2] userns: show current values of user namespace counters

Andrei Vagin <avagin@...tuozzo.com> writes:

> On Thu, Oct 06, 2016 at 02:33:53PM -0500, Eric W. Biederman wrote:
>> Andrei Vagin <avagin@...tuozzo.com> writes:
>> 
>> > Hello Eric,
>> >
>> > What do you think about this series? It should be useful to know current
>> > usage for user counters.
>> 
>> I am in favor of knowing the values.  Unless there is a good reason not
>> to we should export the values with a read-only sysctl.  I believe that
>> is what other similar limits do.
>
> I want to have a place where I will be able to get limits for all
> users. I can't imagine how to do this with a sysctl. It will looks like
> multiline sysct-s, what doesn't look good. I will think. If you will
> have any ideas let me know. Thanks.

Something that has been on my wish list for a while has been to modify
/proc/sys/... to also show up under /proc/<pid>/sys/... for the
non-global values.  Now it might make sense to show these things in an
alternate filesystem.

At the same time I am a little leary of the desire.  Changing these
limits and watching them in a per-process / per-user sense is fine.
However their fundamental purpose is to be set and forget limits and
that only rarely should anyone need to mess with.  Which makes the
primary purpose of looking at them debugging and verifying that the
limits are set to reasonable values.

Active management if someone wants to go there is possible but it will
never be the primary purpose of these limits.

>> As for having per process knowledge I think that is probably something
>> we want to solve for these sysctls as well.
>> 
>> I don't think I saw anyone looking at this code from the perspective of
>> information leaks.  I think we need to ask that question, as similar
>> interfaces have been problematic from an information leak point of view.
>
> It's a good question.

I expect that we don't actually care.  The kernel tends to leak a lot of
this kind of information.  But I figure we should at least be able to
say we thought about it and we don't care.

Eric