Bug 1265406

You _did_ remember beyond that meeting. :)

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_

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

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?

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.

(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

Note. I am on PTO these days. Iwill back on Wed the next week to continue with a discussion about that. Thx.

I would like to schedule a meeting on Wednesday to talk about multiple SELinux and Docker policy stuff.

Did this meeting ever occur?  I'd be interested in the results...

Hopefully tomorrow, 8:00 AM.

(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.

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

Lets start a discussion here.

https://github.com/mgrepl/seatomic/issues/1

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

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.

(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.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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.