On 04/28/2016 11:21 AM, Stephen Smalley wrote:
On 04/28/2016 09:15 AM, Daniel J Walsh wrote:
typebounds unconfined_t docker_t; # docker_t is an unconfined domain
typebounds docker_t spc_t; #spc_t is an unconfined domain
typeboulds docker_t docker_lxc_net_t;
docker, rkt, systemd-nspawn, runc are all executing
setexeccon(svirt_lxc_net_t)
For container domains.
Everything works fine until I turn on expand_check in semanage.conf,
which we have been asked to do in Rawhide.
Attached is the current Rawhide docker policy. And here is the output
from semodule -i before it crashes, with a segfault.
Had to add this rule to make it a little quieter, which is caused by a
rule in policy that says we allow all daemons to connecto spc_t;
gen_require(`
type unconfined_t;
attribute daemon;
')
allow daemon unconfined_t:unix_stream_socket connectto;
Why does typebounds care about when a domain is the target of an access,
I think it should only remove options when it is the source.
Otherwise we end up having to loosen the policy to make this work.
As long as docker_t does not have any more "allow docker_t" rules then
"allow unconfined_t", shouldn't this be ok?
It seems that some or the optional code blocks are causing problems also.
I agree that typebounds is not very usable in its current form, but I'm
not entirely clear on how to fix it.
Dropping the target bounds logic is possible; it was actually
implemented a while back by KaiGai (see the archives) but reverted
because of a side effect on /proc/pid file access. Without the target
bounds logic, you had to allow the parent domain to access all child
domains' /proc/pid files in order for the child to access their own.
That however could be worked around in policy, so possibly we could
revive those patches.
However, I don't think that solves all of the problems. For example,
even with source bounds, I can't allow a child permissions to self or to
its entrypoint file type or to its tmp file type without allowing those
permissions to the parent, which may unnecessarily escalate the
privileges of the parent or expose the parent to risk.
We might need more semantics in the policy about inter-type
relationships in order to truly evaluate bounds in a manner that permits
such usage. Patches/proposals welcome.
The other approach would be to use fork()+setcon()+execve() rather than
fork()+setexeccon()+execve() in the callers. Then you aren't subject to
typebounds at all (NNP only restricts exec-based transitions).
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
BTW doing the
fork()+setcon()+execve()
Is very difficult in golang, do to its strange forkexec() symantecs.
fork()+setcon()+execve()
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
