[Bug 1298539] Re: apparmor rcS.d sysv initscript is running too late

[Jamie Strandboge]

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 changed:

- apparmor's sysv initscript starting late has security implications
- because applications that have apparmor policy defined but don't use an
- upstart job (eg, telepathy-mission-control, tcpdump, evince, firefox,
- etc) may be started before the the sysv init script has a chance to load
- the profiles, resulting in the applications running unconfined.
- 
  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

** Information type changed from Public Security to Public

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/1298539

Title:
  apparmor rcS.d sysv initscript is running too late

Status in “upstart” package in Ubuntu:
  New

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1298539/+subscriptions