Designing the policy for Atomic platforms

[mgrepl]

This issue is created to have a discussion about a basic design of seatomic policy. Once we have some agreed basic concept here it will be a part of Wiki.

[mgrepl]

seatomic policy

Initial draft.

Process labeling

• One process type for all SYSTEM Processes (unconfined_domain) os_t or system_t?
• Docker process and container processes would use separate types. docker_t, spc_t and svirt_lxc_net_t; svirt_sandbox_file_t (Hopefully we can rename these to container_t, and container_file_t or container_content_t)

File system labeling.

• /usr, /bin, /sbin, /src would have a type that can be read/write/execute within the containers (usr_t)?
• /* would have types that are not available to the container at all IE default_t.
• /proc and /sys would have to have labels that containers can read. Probably will need to have some defined types.
• /dev would still be labeled as default_t, IE No access from the containers.
• /var/lib/docker would have labeling provided by the docker-selinux package.

[mgrepl]

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

[rhatdan]

We would need to make sure that docker-selinux package would still work. Currently we rely on virt.pp for this also. Which we might want to also include, since we might want to run svirt_t vms on an atomic host.

[ssekidde]

Will this also include kubernetes policy?
https://github.com/eparis/kubernetes-selinux

[mgrepl]

I believe we would define what core components are going to have own (the current policy).

[rhatdan]

Well k8s will be shipped in a container in the future, so probably not.

[mgrepl]

Also another question is if the current flask is too complex or we need to stay with it as we have it.

[rhatdan]

Not sure what you mean. If it was up to me I think we should attempt a rewrite in CIL. Rethink everything.

[mgrepl]

I meant security classes and permissions.

[rhatdan]

I am fine keeping the same security classes and permissions. But this is something we should open up to upstream SELinux and see if they have ideas of changes then made to SEAndroid that made it easier. It would be nice if we end up with policy as simple as SELAndroid.

[wrabcak]

I like the idea to try reduce current flask for SEAtomic. I believe we could remove some classes and permissions. Definitely, we should discuss this with upstream.

[mgrepl]

The questions if it is applicable here. We still need to have

systemd/journald/kernel/sshd/sssd/docker/virt

as a base and we still need to have a user login domain. I would like to set a base with a policies and ask about it on in upstream

[rhatdan]

I would prefer to not have systemd/journald/kernel/sshd/sssd as different domains, if possible. system_t Then as use cases come up for additional domains, we could add them. Not even sure if you would want a separate user domain unless it is just unconfined_t.

[wrabcak]

Dan,
After my last discussion with Mirek, the concept of merging systemd/journald/kernel/sshd/sssd is actual and will be implemented.

[cgwalters]

Is system_t an unconfined domain?