Date: Fri, 20 Jan 2017 17:33:31 +0100 From: Djalal Harouni <tixxdz@...il.com> To: Andy Lutomirski <luto@...capital.net> Cc: 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>, Lafcadio Wluiki <wluikil@...il.com> 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: > On Thu, Jan 19, 2017 at 5:53 AM, Djalal Harouni <tixxdz@...il.com> 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 do agree, but that's not what we are proposing here. This use case is limited we do not manipulate the creds of the task, there are no security transitions. The task does not change, its only related to procfs and pid entries there. Also the flag applies only to current task and not on remote ones... Nothing new here it's an extension of procfs hidepid. > I'm imaging something like a new RestrictPidVisisbility= option in > systemd. I agree that this is currently a mess to do. But maybe a Yes that's one use case, If we manage to land this I'll follow up with it... plus there is, I've a use case related to kubernetes where I do want to reduce the number of processes inside containers per pod to minimal. Some other cases are: lock down children where being unprivileged. Also as noted in other replies on today's desktop systems, under a normal user session, the user should see all processes of the system where the media player, browser etc have no business to see the process tree. This can be easily implemented when launching apps without the need to regain privileges... > 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. Andy If that could work :-/ we have to re-write or adapt lot of things inside procfs... plus: Procfs is a miror to the current pid namespace. Mount options are not procfs but rather pid namespace. That would not work. Also having multiple mount namespaces where each one with its setup and having to migrate tasks between these environements: I would rather have the security information or context or any minor flag attached to the task itself rather than the object. The prctl() interface is really simple for userspace. The kernel change is not intrusive, and current approach does not require any privileges. For others you may have to gain privileges or ask some one to set it up. The current tendency is to allow more unprivileged code/containers... to setup such mini jails. Note to mention that this schema is simple and can be isolated from other complexities, set it once and that's it. > --Andy -- tixxdz http://opendz.org
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.