All of lore.kernel.org
 help / color / mirror / Atom feed
* We have a pretty big bug between SELinux and the User Namespace
@ 2016-03-10 19:27 Daniel J Walsh
  0 siblings, 0 replies; only message in thread
From: Daniel J Walsh @ 2016-03-10 19:27 UTC (permalink / raw)
  To: SELinux

But our people have limited time to work on it, it has been back 
burner-ed since last summer.

https://bugzilla.redhat.com/show_bug.cgi?id=1236256

Basically User Namespace introduces a new concept of Namespaced 
capabilities.  SELinux currently blocks the use of all capabilities
and does not differentiate.  If someone is looking to cut their teeth on 
Kernel and Security work, I think it would be a good project
to try to differentiate in policy and the kernel between the two 
Capabilities.

The current problem I am seeing is with a confined user.  staff_t does 
not have any capabilities, but when he runs Chrome, it uses
usernamespace to isolate the chrome_sandbox and protect the host. Non 
privilege users on Fedora are allowed to setup User Namespaces
but some of the activity of setting up the User Namespace requires 
Namespaced SYS_ADMIN.  Since SELinux blocks SYS_ADMIN for staff_t
I can not run Chrome with out temporarily setenforce 0, or adding 
SYS_ADMIN to staff_t.  Neither is an attractive solution.

Wearing my best Tom Sawyer hat, white washing this fence would be fun.

Anyone want to take a shot?

Dan

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2016-03-10 19:27 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-10 19:27 We have a pretty big bug between SELinux and the User Namespace Daniel J Walsh

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.