linux-kernel - Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

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: <CALAqxLWQ8hwWyzfUWnXY+oTssqTqyGenbbVFzJ7gzgu-7gWNgg@mail.gmail.com>
Date:   Tue, 4 Oct 2016 12:46:24 -0700
From:   John Stultz <john.stultz@...aro.org>
To:     Tejun Heo <tj@...nel.org>
Cc:     lkml <linux-kernel@...r.kernel.org>, Li Zefan <lizefan@...wei.com>,
        Jonathan Corbet <corbet@....net>, cgroups@...r.kernel.org,
        Android Kernel Team <kernel-team@...roid.com>,
        Rom Lemarchand <romlem@...roid.com>,
        Colin Cross <ccross@...roid.com>,
        Dmitry Shmidt <dimitrysh@...gle.com>,
        Todd Kjos <tkjos@...gle.com>,
        Christian Poetzsch <christian.potzsch@...tec.com>,
        Amit Pundir <amit.pundir@...aro.org>,
        Serge Hallyn <serge.hallyn@...onical.com>
Subject: Re: [RFC][PATCH 0/2] Another pass at Android style loosening of
 cgroup attach permissions

On Tue, Oct 4, 2016 at 12:38 PM, Tejun Heo <tj@...nel.org> wrote:
> Hello, John.
>
> On Tue, Oct 04, 2016 at 11:01:12AM -0700, John Stultz wrote:
>> So to make sure I understand your suggestion, you're suggesting the
>> cgroupfs files like:
>> cpuctrl/tasks,
>> cpuctrl/bg_non_interactive/tasks,
>> cpuset/foreground/tasks,
>> cpuset/background/tasks,
>> etc
>> use ACL permissions to specify the specific uids that can write to
>> them? I guess this would be conceptually similar to just setting the
>> owner to the system task, no?  Though I'm not sure that would be
>
> Yeah, finer grained but essentially just giving write perms.
>
>> sufficient since it would still fail the
>> cgroup_procs_write_permission() checks. Or are you suggesting we add
>> extra logic to make the file owner uid as sufficient to change other
>> tasks?
>
> Hah, now I'm not sure how this is supposed to work inside a userns as
> it's checking against GLOBAL_ROOT_UID.  cc'ing Serge.  Serge, can you
> please have a look?
>
> But back on subject, yeah, I think a capability based approach is
> better here too.  No idea how difficult it is to add a new CAP but I
> think it's worth trying.  Can you please spin up a patch?

Ok. I'll respin this introducing and using a new CAP value.

That said, while CAP_SYS_NICE seems a bit overloaded here, it doesn't
conceptually have that much friction for use with cpuset and cpuctrl
cgroups:

(from the man page: http://man7.org/linux/man-pages/man7/capabilities.7.html )
CAP_SYS_NICE
* Raise process nice value (nice(2), setpriority(2)) and
   change the nice value for arbitrary processes;
* set real-time scheduling policies for calling process, and
  set scheduling policies and priorities for arbitrary
  processes (sched_setscheduler(2), sched_setparam(2),
  shed_setattr(2));
* set CPU affinity for arbitrary processes
  (sched_setaffinity(2));
* set I/O scheduling class and priority for arbitrary
  processes (ioprio_set(2));
* apply migrate_pages(2) to arbitrary processes and allow
   processes to be migrated to arbitrary nodes;
* apply move_pages(2) to arbitrary processes;
* use the MPOL_MF_MOVE_ALL flag with mbind(2) and
  move_pages(2).

If you can tweak nice value and set realtime scheduling policy that
really seems to me just as invasive as what moving tasks between the
cpuctrl and cpuset cgroups could do.

thanks
-john