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.
