On 04/28/2016 02:07 PM, Daniel J Walsh wrote:
>
>
> 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
Hmm...that would appear to be a bug in the libsepol hierarchy checker,
and also in setools3 since it didn't find the match. Just tried
setools4 and it did find the matching rules:
$ ./sesearch -A -s unconfined_t -t cluster_pid -c sock_file
allow domain pidfile:sock_file { write getattr open append };
allow files_unconfined_type file_type:sock_file { rename open execute
execmod setattr read lock create quotaon getattr mounton write
relabelfrom ioctl link relabelto unlink swapon audit_access append };
Yet another reason to switch to setools4...
_______________________________________________
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.
