On 04/28/2016 01:31 PM, Stephen Smalley wrote:
On 04/28/2016 12:20 PM, Daniel J Walsh wrote:
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).
The entrypoints are alot simpler to fix. I think just eliminating the
target checks would
go along way to making this a lot tighter policy.
I have no problem with allowing parent domain access to child domains
self fields. I think this
make some sense. This seems a lot more secure that allowing any domain
that can communicate
with the child to be able to communicate with the parent.
With the way it works now, I can not even figure out how to increase the
privs of unconfined_t or
other confined domains to actually make it work.
Ok, let's assume that we change the libsepol and kernel logic to drop
the target bounds checks. What else remains to make this work?
Looking at the output from the semodule command, I see some other
strange errors like this.
(allow docker_t cluster_pid (sock_file (write getattr append open)))
I have no idea why it would complain about this. Other then potentially
problems caused by optional policy?
BTW, while I think expand-check=1 or manual semodule_link/expand is a
good idea for policy builds, I wouldn't recommend it for the default in
Fedora for users, because it could break locally-generated modules
(particularly audit2allow-generated) or third party modules.
Yes that is a good point. We should probably remove this from Rawhide.
_______________________________________________
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.
