[apparmor] RFC: Policy versioning

Jamie Strandboge jamie at canonical.com
Mon Dec 11 21:35:57 UTC 2017


On Mon, 2017-12-11 at 10:33 -0800, John Johansen wrote:
> On 12/11/2017 09:30 AM, Jamie Strandboge wrote:
> > On Sun, 2017-12-10 at 03:05 -0800, John Johansen wrote:
> > > 
> > > 3. Standardize policy config dir and files
> > > 
> > >   Problem 5 is addressed by standardizing a config directory and
> > > file
> > >   layout. New locations must be added to the config dir to inform
> > >   apparmor of new policy locations and how they should be
> > > handled.
> > > 
> > >   The parser config has proven insufficient so Ubuntu has been
> > >   modifying the initscript to manage this which is not a solution
> > > that
> > >   can be shared across distros, nor does it provide a solution
> > > that
> > >   works with other parts of apparmor like the tools.
> > > 
> > >   Instead we have a directory in which each new location can drop
> > > its
> > >   own config, allowing to set its policy and include location
> > > cache,
> > >   and even compiler options if so desired.
> > > 
> > 
> > This makes a lot of sense. Are you envisioning apparmor would
> > handle
> > all policy loads? For example, today snapd modifies policy in it
> > own
> > area in /var/lib/snapd, outputs cache in /var/cache/apparmor and
> > uses
> > its own options. Setting the cache and options is clear from a
> > snapd-
> > perspective, what does setting the policy location imply? Or put
> > another way, how does this interact with '5', below?
> > 
> 
> Not necessarily, I fully expect lxd and libvirt to still be
> dynamically
> creating and loading policy. This is merely a way of providing the
> tools and initscripts more information so that, they can reload
> those policies if so directed but also can say these are managed
> by lxd.

+1


...

> 
> > > 
> > > 7.2 Supporting unknown rule templates
> > > 
> > >   Instead of wrapping new rule types in conditionals we should
> > > extend
> > >   policy to support rule templates. Rule templates would allow
> > > userspace
> > >   to specify patterns for unknown rule types, so that the parser
> > > or
> > >   tools can parse the rule, and ignore it.
> > > 
> > >   The Rule templates could then be dropped into the abstractions,
> > >   as new features are added providing an easy way to update older
> > >   userspaces to ignore new rule types.
> > > 
> > >   eg.
> > >     if !supports(key) {
> > >       template key='key\w.*,'		# yes its overly
> > > simple
> > >     }
> > > 
> > >   Such rule templates wouldn't completely remove the need for
> > > being
> > >   able to wrap some policy in conditionals, but it done properly
> > > it
> > >   should be able to support most cases.
> > > 
> > 
> > IMO this would make auditing policy a bit harder since you have to
> > either do a preprocess run for auditing (not necessarily a bad
> > thing). 
> > 
> 
> Any worse than wrapping them in conditionals? 

Well, I think I misunderstood what you were proposing. See below

...
> > IIUC, the rule templates put the unix rules somewhere else, outside
> > of
> > the context of the need for the rule.
> > 
> 
> No, no. They are just a way to expand a parsers ability to parse an
> unknown rule just enough so it can skip it and keep processing the
> rules it does know about.
> 
> Think of it as being able to drop a set of rule templates into an
> older version apparmor, so it will support newer policy (yes
> ignoring)
> without doing a full SRU, which will still just result in the rule
> being dropped unless they are using a newer kernel as well.
> 
> The goal is to make it so you won't have to change your policy or
> have multiple versions of policy just because your application is
> running on systems with different versions of apparmor.

This is clear to me now. The policy author can write with the latest
features enabled and the policy packager can put in the templates to
handle new stuff. So long as those templates had clear comments, a
policy auditor focuses on the policy (without conditionals) and would
be able to tell what was available where and how for the exceptional
cases when booting into kernels that don't understand newer policy.

Thinking about this, upstream apparmor could write these templates
alongside the kernel patches introducing the new features so that
distro packagers can just pull these templates in for the new (eg,
upstream) features and SRU (whatever that process is for the particular
distro) those changes (in Ubuntu for example, it might make sense for
the kernel deb to ship these).

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20171211/1a854a2f/attachment.sig>


More information about the AppArmor mailing list