[apparmor] "default"/"system" profile

[Seth Arnold]

On Wed, May 15, 2013 at 05:13:15PM -0700, John Johansen wrote:
> So this is a new attempt to frame the default/init/system profile discussion

Interesting. I like it.

>   There are several potential solutions to the problem of confining init
>   and its early children
>     1. Policy load in the initrd (assuming you have an initrd), and having
>        the early initrd init exec into the system init process
>        This is clean and allows policy to be specified separate from the
>        kernel.

"Clean"-ish. I wouldn't love rebuilding initrd on all my systems all the
time. And I've only got a few..

>     2. special case init and children in the kernel code
>        - No, just no.

No.

>     3. provide a basic policy compiled into the kernel. This is like the
>        initrd solution but is built into the kernel. The initrd solution is
>        more flexible but may not be available on some systems

I dislike this, but grant that we might be able to come up with
something.

>     4. set the profile on individual tasks, after policy load
>        - this is racy as you are chasing different tasks trying to properly
>          confine tasks with the initial profile
>        - this ability does not currently exist and likely won't for a long
>          while

It's hard to see getting this right for all cases.

>     5. provide the ability to replace the initial profile, and accept all
>        tasks under the initial profile will have the same confinement
>        - changing the confinement of the tasks is not really an option as
>          attachments and parent child hierarchy chains aren't reliable
>        - what name to use

This doesn't seem to bad to me. It feels like it'll be only a handful of
long-lived processes -- and is still an improvement over current.

>     6. Put the initial profile into a "complain" like mode where each child
>        process gets its own child profile and the hierarchy is maintained.
>        - this is somewhat racy as you still need to chase down and replace
>          the dynamic profiles before they fork a child and exec to yet
>          another new profile
>        - do not want complain messages to the log, so new mode?

I like this. I fear for the memory consumed if the replacements don't
happen soon. Something more akin to how I imagine TOMOYO has implemented
their process-following state machine thing would be more appealing than
taking our current //null-xxx//null-yyy approach if we're going this far.

>   So without having a more detailed policy defined at boot what can be
>   done?
> 
>   Two profiles could be define at boot (well actually for each namespace),
>   an init and default profile. The init process would start in the "init"
>   profile and at some point the default profile begins to be used. The
>   question is when?
> 
>   a. on every exec until policy is loaded
>      this is equivalent to having the init profile doing pux
> 
>      this is problematic unless the init profile has a defined attachment
>      so that it can keep the init processes in the init profile if it
>      re-execs itself. Also note we can not arbitrarily change what this
>      attachment is at boot. It is possible to have the attachment based on
>      a name and change it at boot time, but the kernel will not have the
>      dfa compiler in it so it is not possible to user regexs as part of
>      the attachment.

This doesn't seem great.

>   b. define an attachment for init
>      the attachment needs to be fixed so it is not flexible to different
>      systems. While the attachment could be defined as a grub boot option
>      it could not use regexes/globbing (so exactly one name).

Probably alright, the exceptions to /sbin/init are probably few..

>   c. once default is loaded
>      in this case init is aliased to the default profile until a new
>      default profile is loaded, at which point the new default takes over.
> 
>      This is different from a in that all the early processes are confined
>      by the init profile, and default is only different once a new one is
>      loaded. This is also racy as to what processes receive a give
>      confinement unless the policy load is ordered and other boot
>      processes wait on it
> 
>   d. A variation of c
>      Except default doesn't have to be loaded, it will go into effect as
>      soon as the first profile is loaded. I would assume it would start
>      out as just the default (unconfined) {} profile.

I go back and forth between these two. (c) feels simpler to describe.
(d) might be simpler to live with.

>   e. build init, and default as actual profiles and compile into the
>      kernel (I am not found of this)
> 
>      The problem with confining early boot and having init have a different
>      profile is that you need a way to identify which processes should be
>      confined by which profiles. The best way to do this is an early policy
>      load, any other solution is somewhat hackish. Splitting the init and
>      default profiles has some merit but the question is it enough for the
>      extra effort. As without a defined early policy we are very limited
>      in how processes are divided between separate init and default
>      profiles.

Anything that requires kernel modifications to change feels too
inflexible, even though we could probably get it to work for most
people without change. (And an rdev-style approach could probably avoid
recompiles.)

Iterating to good profiles for everyone would likely be very painful.

> 
> Aside: the problem with a default profile with broad attachment specification
>   It is possible to define a fixed broad attachment specification for the
>   original default profile, but there is no point as having init use
>   a specific attachment or pux will have the same results. And the broad
>   attachment breaks pix
> 
>   If the default profile is define like
>     profile default /** {
> 
>     }
> 
>   then it will break the fallback in pix rules, where a profile may want
>   to transition to itself if an application profile is not defined,
>   because there is always a profile defined (ie the p portion of the
>   specification always finds a profile and the ix fallback never happens).

Oh. That's an onion in the ointment.

I've got a (small) hope that this, combined with multiple potential
profiles with the FLAG_UNCONFINED mode set, means that pix and pux both
need to change, and in some sort of way that is more beautiful than pix
and pux are now.

Making this hypothesized change not break existing profiles would be an
added complication.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130516/5e062bcd/attachment.pgp>