[apparmor] AppArmor and /etc/

[Jamie Strandboge]

On Fri, 2018-07-27 at 11:10 +0800, intrigeri wrote:
> Christian Boltz:
> > Am Donnerstag, 26. Juli 2018, 13:46:37 CEST schrieb intrigeri:
> > > The initscript has this:
> > > 
> > >    # Required-Start: $local_fs
> > > 
> > > … so I think we should be good when pid 1 == sysvinit as well as
> > > long
> > > as /var is not on a remote FS.
> > > 
> > > Then I'm hesitating between:
> > > 
> > > a) Assume this very unlikely corner-case simply won't be
> > > triggered on
> > >    real-life Buster or newer systems, and then either leave it at
> > > that
> > > or document in README.Debian that one must s/local_fs/remote_fs/
> > > when
> > > using sysvinit + AppArmor + non-local /var.
> > > 
> > > b) Replace that stanza with "Required-Start: $remote_fs"
> > > 
> > >     - pros: avoids the risk of breaking boot in this (corner)
> > > case
> > >     - cons: some services may be started before AppArmor and thus
> > > not
> > >       get the expected confinement unless they explicitly order
> > >       themselves after apparmor
> > > 
> > > Thoughts, opinions?
> > b) has the big disadvantage that it has to wait for the network
> > (and 
> > possibly dhcp to provide an IP address), which makes it *very* late
> > in 
> > the boot cycle, especially if dhcp is used. This obviously means
> > that 
> > some (most?) services will be started before their profile gets
> > loaded.
> 
> Right.
> 
> > OTOH, if a remote /var/ is really not mounted yet, you "only" loose
> > the 
> > profile cache. That slows down boot / loading the profiles, but is
> > still 
> > better than waiting for $remote_fs IMHO.
> 
> I'm not concerned about slowing down boot in this corner case.
> Instead, I am/was concerned about breaking the boot. But it seems
> that
> the parser returns a zero exit code even when its cache-loc is not
> present: a "libapparmor[$pid]: Can't create cache location
> '/non/existing': No such file or directory" message is logged but
> apart of the profiles are loaded just fine. So indeed, maybe there's
> simply no risk of breaking the boot by keeping $local_fs as-is.
> 
> > Therefore I'd vote to keep the $local_fs requirement, even if it
> > slows 
> > down boot in corner cases with non-local /var.
> 
> After doing the aforementioned tests, I now agree. But when reviewing
> my tentative MR to implement this change, Jamie wrote that he agreed
> with switching to $remote_fs, so I'm wary of reverting this change.
> 
> Jamie, what's your reasoning behind "I was leaning towards this too"
> on https://salsa.debian.org/apparmor-team/apparmor/merge_requests/9?
> Would you mind if I reverted to $local_fs, with the above rationale?

I liked that the profiles would be loaded in this corner case, but I
wasn't thinking it would be delayed so long. Note that early boot
profiles and other services like dhclient had historically taken this
into account (at least in Ubuntu) by calling something from
/lib/apparmor/functions to ensure the profile was loaded. It would e
unreasonable IMHO to maintain a delta like this to better support
remote_fs for a corner case for sysvinit, so using local_fs is fine. A
comment in the init script probably makes sense in case people start
investigating.

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- 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/20180730/508b04e1/attachment.sig>