Messages in this thread | | | Date | Wed, 16 Mar 2011 23:04:52 +0200 | From | Alexey Dobriyan <> | Subject | Re: [PATCH] [RFC] Make it easier to harden /proc/ |
| |
On Wed, Mar 16, 2011 at 09:52:49PM +0100, Richard Weinberger wrote: > Am Mittwoch 16 März 2011, 21:45:45 schrieb Arnd Bergmann: > > On Wednesday 16 March 2011 21:08:16 Richard Weinberger wrote: > > > Am Mittwoch 16 März 2011, 20:55:49 schrieb Kees Cook: > > > > On Wed, Mar 16, 2011 at 08:31:47PM +0100, Richard Weinberger wrote: > > > > > When containers like LXC are used a unprivileged and jailed > > > > > root user can still write to critical files in /proc/. > > > > > E.g: /proc/sys/kernel/{sysrq, panic, panic_on_oops, ... } > > > > > > > > > > This new restricted attribute makes it possible to protect such > > > > > files. When restricted is set to true root needs CAP_SYS_ADMIN > > > > > to into the file. > > > > > > > > I was thinking about this too. I'd prefer more fine-grained control > > > > in this area, since some sysctl entries aren't strictly controlled by > > > > CAP_SYS_ADMIN (e.g. mmap_min_addr is already checking CAP_SYS_RAWIO). > > > > > > > > How about this instead? > > > > > > Good Idea. > > > May we should also consider a per-directory restriction. > > > Every file in /proc/sys/{kernel/, vm/, fs/, dev/} needs a protection. > > > It would be much easier to set the protection on the parent directory > > > instead of protecting file by file... > > > > How does this interact with the per-namespace sysctls that Eric > > Biederman added a few years ago? > > Do you mean CONFIG_{UTS, UPC, USER, NET,}_NS?
It only covers /proc/sys/net/
> > I had expected that any dangerous sysctl would not be visible in > > an unpriviledge container anyway. > > No way.
No way what exactly?
> That's why it's currently a very good idea to mount /proc/ read-only into a container. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |