Re: Strange behavior: type boundaries

[Dominick Grift <dac.override@gmail.com>]

[-- 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 --]