linux-kernel - Re: [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: <CAOWbf6e7V77TpUYJwRdmD9vyeqA14hbL-HZqweTEign-hUSKiQ@mail.gmail.com>
Date:   Thu, 3 Nov 2016 14:21:41 -0600
From:   Lafcadio Wluiki <wluikil@...il.com>
To:     Jann Horn <jann@...jh.net>
Cc:     linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        kernel-hardening@...ts.openwall.com
Subject: Re: [2/2] procfs/tasks: add a simple per-task procfs hidepid= field

On Thu, Nov 3, 2016 at 12:24 PM, Jann Horn <jann@...jh.net> wrote:

>> +     case PR_SET_HIDEPID:
>> +             if (arg2 < HIDEPID_OFF || arg2 > HIDEPID_INVISIBLE)
>> +                     return -EINVAL;
>> +             if (arg2 < me->hide_pid)
>> +                     return -EPERM;
>> +             me->hide_pid = arg2;
>> +             break;
>
> Should we test for ns_capable(CAP_SYS_ADMIN)||no_new_privs here?
> I think it wouldn't hurt, and I'd like to avoid adding new ways in which
> the execution of setuid programs can be influenced. OTOH, people already
> use hidepid now, and it's not an issue... I'm not sure. Opinions?

Hmm, the existing hidepid= thing is a mount option and that you you of
course can only change with root privs so far, hence the NNP thing
doesn't really apply so far on hidepid.

> @Lafcadio: Do you think that requiring no_new_privs to be set would
> break your usecase? Would nginx need to still be able to execute setuid
> binaries?

I think adding the NNP check would be OK for my use. I'll add this to
the next iteration!

> Aside from this, and the comments Kees already made, this looks good
> to me.

Thanks for the review,

L.