Strange behavior: type boundaries

Strange behavior: type boundaries

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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 

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJVAykfAAoJENAR6kfG5xmch6kL/iR7H5pZCD8kDbpKgNGm6PIS
XemC/HnvH2sH+TluECQ6aYzf/nFR+aHAWkh4TOP7JwHE1nQQifTpaWIQsTWl7zuk
DEaOjxvnezgfH+kwLX4uyONgsq6cDyRf/Uo6fcooaDxmxOnC9eOcA7OPt7FdGdbI
Mi+0qpv5Z+RRtDfDxZ5jDTCi5iQiV3WwVj9sa+z5vvV6H807iyCAWa/cY3Cj+yAu
Q5yLChm5GZpANjAPxWSNzLrOxIl71cZDO+kAMvpKoSGvw63W7JgchzWJLn68EjjZ
MUaDJTIeOo2RbDoc1fRP/+KmBy9r9gz6VF6mkhokTlDPHwoL76jO5Ks8JEuN958/
Q/8uKedNJ71osR2ynZK+KEk2Sih/TLN8XoWgGapeTfBrfvPL05MCtCt0vdbO2DXH
N81BeoP7lasEO9N32wS3agOjwXlMdYP9hBeQmXWM6dgPN/7br9tchodM1sRddJhe
/LcfCkE1gaPMHlDkOrHvsn8P6oW35ItaLxyVlexAJg==
=YVmE
-----END PGP SIGNATURE-----

Re: Strange behavior: type boundaries

[Stephen Smalley]

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.

Re: Strange behavior: type boundaries

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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.

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

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJVAy/OAAoJENAR6kfG5xmcrpwL/jzgt80iZDtJoQKBd90MzV/W
Z9ldbnPK13hWpYGTJxOTS8MknMMUwb3wT9nBwMeg6rF8K6lNvutsXxHEGHzgMwdT
WpYlI2gH/TUba8PL9poV7sL+tCdjpR5pAbQiZmFYZHYvlH2xg2jlSJ2a4lEwCKxJ
Y3YnMUYTVBUjWqYzzVsTtwu939MqDGpON77NO/TtJ4eogAb5eNeybxZnDZPHPc7m
qgYCV3KBFBmNH6aslaVV/U0U+/n3VOjVoZS0g9IKFoRn1noOONeERbzj9Lw1vxek
cytAvnDGqofRRVd7b2WpCrFVUjdniI/keg6kVXfPpwuTLPiIm/g+RGymkMWvGEbH
O7fGurpoHDKj1XMOAn9LbgRaHQoaAUpaW2VpOLCkt0lAnQK9nQHSWq5lf6VcgQSQ
vB2miUPeELW2o3LhltL+5gCiBEvjkuaBqYj+h0n2YBG9JzXvwvT1g/qNA1kkWpLp
Yq4hIoVemD5ObjD3xJCr3w1IH3FpvloMY4s/2EmZfA==
=hnz3
-----END PGP SIGNATURE-----

Re: Strange behavior: type boundaries

[Stephen Smalley]

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?

Re: Strange behavior: type boundaries

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 5375 bytes --]

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?

It has a lot but not that:

# sesearch -A -s systemd_t -t systemd_t -c process
Found 3 semantic av rules:
   allow subject_type systemd_t : process sigchld ; 
   allow systemd_t systemd_t : process { fork sigchld sigkill sigstop signull signal getsched setsched getcap setcap setexec setfscreate setrlimit setkeycreate setsockcreate } ; 
   allow systemd_t subject_common_type : process { sigkill signull signal getattr } ; 

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

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: Strange behavior: type boundaries

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 5208 bytes --]

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.

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

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: Strange behavior: type boundaries

[Stephen Smalley]

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.

Re: Strange behavior: type boundaries

[Steve Lawrence]

On 03/16/2015 08:43 AM, 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.
> 
> 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.
> 

I suspect Dominick is using secilc to build this, which doesn't use
expand_module for generating binaries. Looks like we are missing this
check in CIL.

Re: Strange behavior: type boundaries

[Miroslav Grepl]

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.

Re: Strange behavior: type boundaries

[Stephen Smalley]

On 06/22/2015 12:07 PM, Miroslav Grepl wrote:
> 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.

But the bounds check is only applied if the caller or one of its
ancestors (systemd?) set NO_NEW_PRIVS or the filesystem is mounted nosuid.

And if the type is not bounded, we simply fall back to the original
context on a default transition, just as we did unconditionally prior to
the kernel change when NO_NEW_PRIVS was set.  The kernel change did not
make type bounds a requirement; it just added it as an optional way of
support type transitions under NO_NEW_PRIVS.  Prior to the kernel
change, there was no way to perform a type transition upon exec if
NO_NEW_PRIVS was set.

What definition of typebounds would permit the above scenario yet still
ensure that no privilege escalation can result?  Would we need special
case handling of :file entrypoint and possibly self: rules (to address
Dominick's earlier issue)?  Or dropping the target bounds checks
entirely as was proposed back in
http://marc.info/?l=selinux&m=125770868309928&w=2 ?

Re: Strange behavior: type boundaries

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

On Mon, Jun 22, 2015 at 12:28:03PM -0400, Stephen Smalley wrote:
> But the bounds check is only applied if the caller or one of its
> ancestors (systemd?) set NO_NEW_PRIVS or the filesystem is mounted nosuid.
> 
> And if the type is not bounded, we simply fall back to the original
> context on a default transition, just as we did unconditionally prior to
> the kernel change when NO_NEW_PRIVS was set.  The kernel change did not
> make type bounds a requirement; it just added it as an optional way of
> support type transitions under NO_NEW_PRIVS.  Prior to the kernel
> change, there was no way to perform a type transition upon exec if
> NO_NEW_PRIVS was set.
> 
> What definition of typebounds would permit the above scenario yet still
> ensure that no privilege escalation can result?  Would we need special
> case handling of :file entrypoint and possibly self: rules (to address
> Dominick's earlier issue)?  Or dropping the target bounds checks
> entirely as was proposed back in
> http://marc.info/?l=selinux&m=125770868309928&w=2 ?
> _______________________________________________

For the record. I accepted things the way they are now. Sure it is not perfect but I learned to compromize

The only encounter i had with this was with systemd-importd.

Any other app/service that has the same requirements just needs to be targeted and dealt with accordingly

If something that is not targeted then so be it. Not supported until i target it.

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: Strange behavior: type boundaries

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

On Mon, Jun 22, 2015 at 06:07:20PM +0200, Miroslav Grepl wrote:

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

What is running in the unconfined_service_t domain in that event?

> -- 
> Miroslav Grepl
> Senior Software Engineer, SELinux Solutions
> Red Hat, Inc.
> _______________________________________________
> 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.

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: Strange behavior: type boundaries

[Stephen Smalley]

On 06/22/2015 02:08 PM, Dominick Grift wrote:
> On Mon, Jun 22, 2015 at 06:07:20PM +0200, Miroslav Grepl wrote:
> 
>>
>> 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.
>>
> 
> What is running in the unconfined_service_t domain in that event?

Nothing at the point of that message.  The message indicates a bounds
failure, which will then cause the kernel to fall back to the old
context if it was an automatic transition, or fail the exec with -EPERM
if it was explicitly requested via setexeccon().

Re: Strange behavior: type boundaries

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]

On Mon, Jun 22, 2015 at 02:17:32PM -0400, Stephen Smalley wrote:
> On 06/22/2015 02:08 PM, Dominick Grift wrote:
> > On Mon, Jun 22, 2015 at 06:07:20PM +0200, Miroslav Grepl wrote:
> > 
> >>
> >> 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.
> >>
> > 
> > What is running in the unconfined_service_t domain in that event?
> 
> Nothing at the point of that message.  The message indicates a bounds
> failure, which will then cause the kernel to fall back to the old
> context if it was an automatic transition, or fail the exec with -EPERM
> if it was explicitly requested via setexeccon().
> 

Sounds reasonable to me (it just seems I can't get easily used to that message but that is probably just because it does not happen often)

But yes at that point, suppose you know you have something to target.

I still would like to know what triggered this. Only thing i can think of is systemd-importd

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: Strange behavior: type boundaries

[Miroslav Grepl]

On 06/22/2015 08:17 PM, Stephen Smalley wrote:
> On 06/22/2015 02:08 PM, Dominick Grift wrote:
>> On Mon, Jun 22, 2015 at 06:07:20PM +0200, Miroslav Grepl wrote:
>>
>>>
>>> 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.
>>>
>>
>> What is running in the unconfined_service_t domain in that event?
> 
> Nothing at the point of that message.  The message indicates a bounds
> failure, which will then cause the kernel to fall back to the old
> context if it was an automatic transition, or fail the exec with -EPERM
> if it was explicitly requested via setexeccon().
> 

Please, forget about it. It works as expected. Sorry for the noise.
> 
> _______________________________________________
> 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.