Re: Strange behavior: type boundaries

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

 



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.

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@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