apparmor rcS.d sysv initscript is running too late

Bug #1298539 reported by Jamie Strandboge on 2014-03-27
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
upstart (Ubuntu)
Undecided
Unassigned

Bug Description

From IRC:

12:50 < infinity> jdstrand: Could it be that slangasek's assertion about network interfaces only delaying rc2 is wrong, and it in fact delays all of sysvinit? That would pretty much explain that paste.
...
12:53 < slangasek> ok, so /etc/init.d/rcS is run from the bottom of /etc/init/rc-sysinit.conf, which does key on static network up
12:53 < slangasek> I thought we had better interleaving of /etc/rcS.d with the rest of the system
12:53 < slangasek> jdstrand: so yeah, any late apparmoring that you're seeing is actually related to us having made /etc/rc2.d non-racy, without noticing that this also holds up /etc/rcS.d :/
12:54 < slangasek> proper fix would be to split out /etc/rcS.d handling, and make it wait for the local filesystem but not the network
12:54 < infinity> slangasek: So, curious followup. Why do I have a console?
12:54 < jdstrand> slangasek: oh! it is great to know the cause
12:55 < infinity> slangasek: My hvc0 job is "start on stopped rc RUNLEVEL=[2345]", is that basically a complete lie, given how we're running rcS/rc2?
12:56 < jdstrand> slangasek: since I use network-manager, the fact that I don't see it locally is consistent with your understanding of the issue, correct?
12:56 < slangasek> jdstrand: correct
12:57 < jdstrand> I never saw it in a vm cause I almost always do desktop installs in them
12:57 < slangasek> infinity: ummmm ok, yeah, I don't know why you would have a console with output from rc2.d showing up then
12:58 < slangasek> infinity: because 'stopped rc RUNLEVEL=[2345]' should mean the console starts only after all of rc2.d is done running
12:58 < infinity> slangasek: That's what I would think, yes.
12:58 < jdstrand> slangasek: so, is there something that can be done for 14.04 for this? (like I said, we can't to the cache pregeneration/upstart job change before 14.10/SRU)
12:59 < infinity> slangasek: And really, while delayed boots are annoying (and they are), the larger complaint is actually that these late starts scribble all over the getty, making it confusingly non-obvious that a login prompt has happened. :P

description: updated
description: updated
Jamie Strandboge (jdstrand) wrote :

Any progress on this bug? It prevents an important security measure from being in effect.

tags: added: rls-t-incoming
Steve Langasek (vorlon) wrote :

Having discussed on IRC, I don't believe /etc/init/rc-sysinit.conf being delayed explains the symptoms described. User processes are started from a login session, which would be launched via lightdm; lightdm is 'start on runlevel and [...]', and the runlevel event is strictly later than the point at which we run the rcS scripts from rc-sysinit.conf.

If this were processes related to individual upstart jobs in /etc/init that might start before runlevel 2, then this could explain it; but given the problem described is with firefox being unconfined, that doesn't seem related to the delayed apparmor profile loading because firefox and lightdm are also delayed in that case.

Dimitri John Ledkov (xnox) wrote :

we could move just run profile loading earlier, ahead of remote filesystems, as an upstart job:

description "Pre-cache and load apparmor profiles"
task
start on local-filesystems and not-container
script
 . ./lib/apparmor/functions
 [ -w "$AA_SFS"/.load ] || { stop; exit 0; }
 load_configured_profiles
end script

Also desktop is a bit too quick to observe the ordering here. But e.g. it looks like on ubuntu-touch network-manager is started ahead of loading all apparmor profiles, the network-manager job does not load profiles for binaries that it uses and it can spawn e.g. dhclient see:
http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-283.png

dhclient did not execute ahead of apparmor_profile launched by xargs, but it think it could be on a cold boot when profiles are regenerated for all .clicks.

Jamie Strandboge (jdstrand) wrote :

xnox and I discussed this quite a bit and I filed bug #1305108 to deal with apparmor policy load. Since slangasek believes the console logging to be a different issue, lets separate the issues and use this bug for console logging and bug #1305108 for policy load (since this bug has all the irc conversation for console logging).

description: updated
information type: Public Security → Public
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers