Bug 1265406 - We need a new selinux-policy-atomic
We need a new selinux-policy-atomic
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
24
Unspecified Unspecified
high Severity medium
: ---
: ---
Assigned To: Lukas Vrabec
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-22 16:34 EDT by Daniel Walsh
Modified: 2017-07-06 21:22 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-06 21:22:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Walsh 2015-09-22 16:34:08 EDT
Since we designed a new system atomic platform.  I believe it is time for a simplified policy for atomic platform that just ships atomic policy.


Lets minimize policy down to systemd/journald/kernel/sshd/sssd/docker/virt.

Just about everything else could be eliminated.
Comment 1 Matthew Miller 2015-09-22 17:34:18 EDT
You _did_ remember beyond that meeting. :)
Comment 2 Matthew Miller 2015-09-22 17:39:30 EDT
Maybe this is optimistic, but outside of the listed components, it seems like most everything could be tightened down by default rather than unconfined. On default general-purpose cloud image, we have to allow the possibility for people to do things we haven't even imagined. But with Atomic, they should do that inside containers, and only do a relatively limited subset outside. So it's a double win:

* Less complicated policy
* But yet protects _more_
Comment 3 Stephen Smalley 2015-09-23 09:12:52 EDT
This is more or less how we designed the Android SELinux policy.  With 5.0 Lollipop and later, there is nothing fully unconfined, yet the policy is vastly smaller and simpler than Fedora.  It helps though that in Android they had clear delineations, e.g. most privileged actions restricted to init, operating system files mounted read-only except during updates, apps cannot run with root privileges/capabilities, etc.

To keep the policy small, we need to keep the number of types small.
So we should revisit not merely what domains are defined but the file type definitions and assignments.  Types are equivalence classes, and you should only have different types when you need to make a security distinction (e.g. read-only vs read-write, executable vs non-executable, accessible by A but not by B).

We should define a set of base security goals for the policy up front and enforce them via neverallow rules (policy assertions).  This requires building policy with neverallow checking enabled (disabled last I looked in Fedora policy).  Android has a number of these rules to ensure that we do not regress.

Android SELinux policy source lives here:
https://android.googlesource.com/platform/external/sepolicy
Comment 4 Colin Walters 2015-09-23 14:06:33 EDT
I think we still need an unconfined domain for interactive administrative logins (sshd), right?  Supporting that is a major distinction from Android.

As far as security goals - I'd like to figure out how to better support downstream system administrators applying a set of more coarse grained policies to generic software.  This is different from Android, where at least for consumers, there is no system administrator.  

(I don't know much about enterprise Android - does it support administrators applying custom policy for applications?)

This would also be different than traditional packaging, where for Fedora there is mostly one centrally maintained policy.

What I mean by "coarse grained" is things like svirt_lxc_{net,}_t where the "net" means "can do non-local networking", "can execute setuid binaries", "can use user namespaces"?

It's also worth looking at this from a Kubernetes perspective - what communication needs to occur inside a pod, and how can we more strongly isolate pods from each other?  Particularly for a multitenant scenario, we should be able to prevent pods from different tenants by default from consuming services offered by another tenant unless that's been authorized.

Is there a way we can use MCS/MLS to dynamically say on a particular host "these two pods can talk"?  Or maybe policy should be generated centrally and synchronized out to nodes.

What avenues of communication are *not* covered by kernel namespaces but are by MAC?
Comment 5 Daniel Walsh 2015-09-23 15:43:40 EDT
I would like to go one step further with this to define a new type like sssd_container_t.  (Which we are talking about internally).

This container would run with MCS Separation for protection, but would allow access from all containers to talk to it via UnixDomainSockets, though 

/var/lib/sss, which we could label as sssd_var_lib_t or some type. 

Then 

allow domain sssd_container_t:unix_stream_socket connectto;

We also want to have an MCS override for talking over unix_stream_sockets, so we can continue to have sssd_container_t content protected. 

In the container world we probably do not care much about the tcp_sockets a confined process can listen on, since this is isolated by the network namespace, but we probably want to control outbound connections.
Comment 6 Miroslav Grepl 2015-09-25 03:46:38 EDT
(In reply to Stephen Smalley from comment #3)
> This is more or less how we designed the Android SELinux policy.  With 5.0
> Lollipop and later, there is nothing fully unconfined, yet the policy is
> vastly smaller and simpler than Fedora.  It helps though that in Android
> they had clear delineations, e.g. most privileged actions restricted to
> init, operating system files mounted read-only except during updates, apps
> cannot run with root privileges/capabilities, etc.
> 
> To keep the policy small, we need to keep the number of types small.
> So we should revisit not merely what domains are defined but the file type
> definitions and assignments.  Types are equivalence classes, and you should
> only have different types when you need to make a security distinction (e.g.
> read-only vs read-write, executable vs non-executable, accessible by A but
> not by B).
> 

Yes, I totally agree here.

> We should define a set of base security goals for the policy up front and
> enforce them via neverallow rules (policy assertions).  This requires
> building policy with neverallow checking enabled (disabled last I looked in
> Fedora policy).  Android has a number of these rules to ensure that we do
> not regress.

Good news, we already enabled them in rawhide again.

> 
> Android SELinux policy source lives here:
> https://android.googlesource.com/platform/external/sepolicy
Comment 7 Miroslav Grepl 2015-09-25 03:50:15 EDT
Note. I am on PTO these days. Iwill back on Wed the next week to continue with a discussion about that. Thx.
Comment 8 Daniel Walsh 2015-09-25 09:52:57 EDT
I would like to schedule a meeting on Wednesday to talk about multiple SELinux and Docker policy stuff.
Comment 10 Stephen Smalley 2015-10-13 16:49:57 EDT
Did this meeting ever occur?  I'd be interested in the results...
Comment 11 Daniel Walsh 2015-10-13 16:51:15 EDT
Hopefully tomorrow, 8:00 AM.
Comment 12 Paul Moore 2015-10-13 17:26:53 EDT
(In reply to Daniel Walsh from comment #11)
> Hopefully tomorrow, 8:00 AM.

FYI, I don't have anything on my calendar for this meeting.
Comment 15 Daniel Walsh 2015-10-14 09:40:23 EDT
Stephen we met this morning and started throwing together ideas about what the new policy should look like.  Miroslav will be putting together a document, that we will send the the selinux list and atomic-devel list for comments.  There was some talk about a using a higher level lanquage then CIL to do the new policy, but to my knowledge no language exists.  I also think writing the initial policy in CIL will help us know what the shortcoming of CIL as a low level language are, so we could suggest improvements in newer languages.

One requirement that I have is that docker-selinux package will be able to work with the new selinux-policy-atomic as well as selinux-policy-targeted, since it will be installed on both RHEL/Fedora/Centos and Atomic systems
Comment 16 Miroslav Grepl 2015-12-02 03:26:19 EST
Lets start a discussion here.

https://github.com/mgrepl/seatomic/issues/1
Comment 17 Jan Kurik 2016-02-24 10:47:56 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Comment 18 Colin Walters 2016-03-31 16:19:53 EDT
FWIW I am not ignoring this but basically right now Atomic Host is too much of a second class citizen right now, and that inhibits our ability to carry more of a delta from "mainline".  If we improve our testing story and get more people developing and using it I think we can consider having a custom SELinux policy.
Comment 19 Miroslav Grepl 2016-04-01 05:45:08 EDT
(In reply to Colin Walters from comment #18)
> FWIW I am not ignoring this but basically right now Atomic Host is too much
> of a second class citizen right now, 

Can you elaborate it more?

> and that inhibits our ability to carry
> more of a delta from "mainline".  If we improve our testing story and get
> more people developing and using it I think we can consider having a custom
> SELinux policy.
Comment 20 Fedora Admin XMLRPC Client 2016-09-27 11:14:54 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 21 Colin Walters 2017-06-23 10:49:30 EDT
I propose closing this.  Given that rpm-ostree now has package layering, and further there are (AFAIK) no plans to drop the "traditional RPM" path, there's no really good reason to introduce a separate policy, and a *whole lot* of downsides in terms of testing.

Note You need to log in before you can comment on or make changes to this bug.