Re: Trying to setup a type bounds from unconfined_t and docekr_t to svirt_lxc_net_t

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 04/28/2016 01:59 PM, Stephen Smalley wrote:
On 04/28/2016 01:35 PM, Daniel J Walsh wrote:

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?
$ sesearch -A -s docker_t -t cluster_pid -c sock_file
Found 1 semantic av rules:
    allow daemon cluster_pid : sock_file { write getattr append open } ;

$ sesearch -A -s unconfined_t -t cluster_pid -c sock_file
<no output>

So that is a legitimate violation of the bound and would be denied by
the kernel if it were attempted.  Either you need to allow it to
unconfined_t or tighten up that rule so that docker_t isn't included
(why should all daemon domains be allowed to do that?).

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


allow files_unconfined_type file_type:{ dir lnk_file sock_file fifo_file blk_file } *;

So unless cluster_pid refers to something that is not a file_type, then I think unconfined_t can do it.
No idea why this is allowed.

seinfo -acluster_pid -x
   cluster_pid
      dlm_controld_var_run_t
      fenced_var_run_t
      foghorn_var_run_t
      gfs_controld_var_run_t
      haproxy_var_run_t
      groupd_var_run_t
      qdiskd_var_run_t
      cluster_var_run_t

Probably because of you can run any daemon on a cluster and they have to be able to write to the cluster socket files.
_______________________________________________
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.



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux