Re: Strange behavior: type boundaries

[Miroslav Grepl <mgrepl@redhat.com>]

On 03/16/2015 01:43 PM, Stephen Smalley wrote:
> On 03/14/2015 03:22 AM, Dominick Grift wrote:
>> On Fri, Mar 13, 2015 at 02:50:10PM -0400, Stephen Smalley wrote:
>>> On 03/13/2015 02:43 PM, Dominick Grift wrote:
>>>> On Fri, Mar 13, 2015 at 02:26:21PM -0400, Stephen Smalley wrote:
>>>>> On 03/13/2015 02:15 PM, Dominick Grift wrote:
>>>>>> I was playing with systemd-nspawn/machine, and machinectl allows one to pull in images. I am trying to confine it and i hit issues:
>>>>>>
>>>>>> systemd runs systemd-importd, and systemd-importd runs systemd-pull
>>>>>>
>>>>>> It seems as if though its some multithreading going on because i get:
>>>>>>
>>>>>> type=SELINUX_ERR msg=audit(1426268982.258:2559): op=security_bounded_transition seresult=denied oldcontext=system_u:system_r:systemd_t newcontext=system_u:system_r:importd_t
>>>>>>
>>>>>> Even though I am in permissive mode, and a transition rule "allow systemd_t importd_t:process transition;" is present, SELinux does not transition.
>>>>>>
>>>>>> When i add a typebounds statement (typebounds systemd_t importd_t), then the scenario changes:
>>>>>>
>>>>>> type=SELINUX_ERR msg=audit(1426268121.044:2414): op=security_compute_av reason=bounds scontext=system_u:system_r:systemd_t tcontext=system_u:system_r:importd_t tclass=process perms=transition
>>>>>> ----
>>>>>> type=AVC msg=audit(1426268121.044:2415): avc:  denied  { transition } for  pid=9210 comm="(-importd)" path="/usr/lib/systemd/systemd-importd" dev="dm-1" ino=2232532 scontext=system_u:system_r:systemd_t tcontext=system_u:system_r:importd_t tclass=process permissive=1
>>>>>> ----
>>>>>> type=SELINUX_ERR msg=audit(1426268121.044:2416): op=security_compute_av reason=bounds scontext=system_u:system_r:importd_t tcontext=system_u:object_r:importd_exec_t tclass=file perms=entrypoint
>>>>>> ----
>>>>>> type=AVC msg=audit(1426268121.044:2417): avc:  denied  { entrypoint } for  pid=9210 comm="(-importd)" path="/usr/lib/systemd/systemd-importd" dev="dm-1" ino=2232532 scontext=system_u:system_r:importd_t tcontext=system_u:object_r:importd_exec_t tclass=file permissive=1
>>>>>> ----
>>>>>> type=SELINUX_ERR msg=audit(1426268121.046:2418): op=security_compute_av reason=bounds scontext=system_u:system_r:importd_t tcontext=system_u:system_r:systemd_t tclass=fd perms=use
>>>>>> ----
>>>>>> type=AVC msg=audit(1426268121.046:2419): avc:  denied  { use } for  pid=9210 comm="systemd-importd" path="/dev/null" dev="devtmpfs" ino=1028 scontext=system_u:system_r:importd_t tcontext=system_u:system_r:systemd_t tclass=fd permissive=1
>>>>>>
>>>>>> These rules are present in the policy (the transition is obviously taking place in permissive mode) and so is the typebounds rule, but access looks still denied.
>>>>>>
>>>>>> I do not understand what is going on here.
>>>>>>
>>>>>> First of all importd_t is bounded to systemd. So why does it appear to be a problem that systemd operates on importd_t entities?
>>>>>>
>>>>>> Also why does selinux refuse to type transition without a typebounds, and why does it give me a permission denied with a typebounds 
>>>>
>>>>> NO_NEW_PRIVS?  See http://marc.info/?l=selinux&m=140717412324539&w=2
>>>>> Previously domain transitions on exec were always disabled under
>>>>> NO_NEW_PRIVS and nosuid mounts.  This was introduced as a way of
>>>>> supporting e.g. the SELinux sandbox or other cases where NNP is being
>>>>> used and they want to transition domains on exec.  Typebounds makes this
>>>>> safe, but typebounds requires you to cap the child type's permissions to
>>>>> a subset of the parent type's permissions.  This is normally checked by
>>>>> checkpolicy or libsemanage at policy build/link time but I'm sure Red
>>>>> Hat has disabled it along with neverallow checking, so you probably
>>>>> don't see it until the kernel recognizes the discrepancy and dynamically
>>>>> blocks the access that would violate the bound.
>>>>
>>>> Yes that is what i mentioned on #selinux. However i am not using checkpolicy or libsemanage. I am using secilc (and i have it check for neverallow rule violations). I would have expected it to catch it on compile time.
>>>>
>>>> However there is still something strange in that importd_t is bounded to systemd_t: thus why would: "systemd_t importd_t:process transition;" be denied?
>>>>
>>>> systemd_t is the parent and not the bounded child.
>>>>
>>>> A rule "allow systemd_t importd_t:process transition;" is present in the output of "sesearch -A -s systemd_t -t
>>> importd_t". Yet it still prints a denial.
>>>
>>> Typebounds restricts its use both as a source and as a target context.
>>> Does systemd_t have transition to self?
>>
>> Thanks for the hint. That did it.
>>
>> It feels wrong/unnatural though because now i have to give the parent more permissions to be able to run the child with less permissions than its parent.
>>
>> But ce'st la vie i suppose. At least i know what the problem was now.
> 
> I agree that the typebounds logic is somewhat less than optimal presently.

In Fedora, we have unconfined_service_t domain for unconfined services
started by init. So there is init_t @bin_t -> unconfined_service_t and
we get op=security_bounded_transition for init_t against
unconfined_service_t. But of course it is not going to work with

typebounds init_t unconfined_service_t;

because there is

# <audit-1401> op=security_compute_av reason=bounds
scontext=system_u:system_r:unconfined_service_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file perms=entrypoint

So this logic breaks our concept with unconfined_service_t.


> 
> See prior discussions in http://marc.info/?l=selinux&m=125770868309928&w=2
> which led to:
> http://marc.info/?l=selinux&m=126396240001706&w=2
> http://marc.info/?l=selinux&m=126396240301719&w=2
> later reverted by:
> http://marc.info/?l=selinux&m=126636445922501&w=2
> 
> If we could come to consensus on what the right logic is, we could look
> at changing it.
> 
> There is the separate question of why the libsepol
> hierarchy_check_constraints() check wasn't being performed when you
> built your policy.  This is a separate function from check_assertions(),
> used for neverallow checking, but normally they are both called or
> neither called by expand_module() based on the check argument.
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> 


-- 
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.