[apparmor] Query about AppArmor's Profile Transitions

[Christian Boltz]

Hello,

Am Donnerstag, 3. Oktober 2019, 07:21:26 CEST schrieb Abhishek Vijeev:
> We had a good look at stacking, but it doesn't seem to help accomplish
> quite what we have in mind:
> 
> a) Confine 'init'
> b) When init executes any other process, perform a discrete profile
> transition. But, if no discrete profile exists, transition to a
> 'default' (highly restricted) child profile defined in init's profile
> (this is basically what would be a 'pcx' transition).

Ah, so you are looking for full system confinement with profiles for 
specific programs, and a default profile for everything else.

You might want to check the list archives [1] from May and June 2019 for
    [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...
This thread should answer quite some questions around confining init and 
doing a full system confinement.

> Even if we were to specify the default profile as a discrete profile,
> the following example is the closest that stacking can bring us to
> what we would like, and hopefully illustrates our problem better:
> 
> profile init-systemd /**
> {
>      /program px -> program //& default
> }
> 
> profile default
> {
>      . . .
> }
> 
> a) If the discrete profile for 'program' doesn't exist, I understand
> that 'program //& default' would evaluate to just 'default', which is

I'm afraid you are wrong here - either both profiles "program" and 
"default" exist (and get both used), or you'll get an exec denial if one 
of the target profiles doesn't exist.


Regards,

Christian Boltz

[1] https://lists.ubuntu.com/archives/apparmor/
-- 
 ... you start off with a typical message,
let's say a 2.5MB Word document containing
three lines of text and a macro virus ...
[Peter Gutmann]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20191003/82629ab4/attachment.sig>