(sorry, I meant to say I saw the results of comment #3 after reboot)
** Also affects: apparmor (Ubuntu Trusty)
Importance: Undecided
Status: Confirmed
** Also affects: apparmor (Ubuntu U-series)
Importance: Undecided
Status: New
** Changed in: apparmor (Ubuntu U-series)
Status: New => Confirmed
** Changed in: apparmor (Ubuntu Trusty)
Status: Confirmed => New
** Description changed:
AppArmor has a complicated multi-stage policy load process that has evolved
over time. It consists of:
- /etc/init/network-interface-security.conf to load the policy for dhclient
- /etc/init/click-apparmor.conf to conditionally regenerate click policy then
load it into the kernel
- apparmor integration into upstart jobs
- an rcS sysv init script
In addition to being complicated, there are a several problems:
- if a login session occurs before rcS is run, applications may start and run
unconfined
- if apparmor-profiles is installed, then daemons with profiles defined may
start and run unconfined
- an administer adding apparmor policy for daemons must also adjust the
upstart job for the daemon
Historically we did not use an upstart job because it would block boot
and affect boot performance. Blocking boot on policy load is actually a
feature because it ensures that the policy is in place before anything
is started. The boot performance issue was solved long ago when we
introduced binary cached profiles. In today's upstart world, rcS is
intended to run prior login anyway, so converted the initscript to an
upstart job should not affect boot performance. There have also been
bugs in the multi-stage policy load that allowed policy load to happen
too late with applications starting before policy load.
The security and foundations teams feel there is a better way and that
we can achieve everything with a single upstart task (see attached). In
essence, the task does 'start on mounted MOUNTPOINT="/"'. Because it is
a task, it will block until it completes. The script will do the various
checks to make sure apparmor should load policy, conditionally
regenerate click policy then load it into the kernel and load all system
policy.
If done correctly, this should allow us to remove the
network-interface-security.conf job, the click-apparmor.conf job and the rcS
initscript and will solve the issues with login sessions starting too soon,
apparmor-profiles daemon policy and admin policy. Attached is lightly tested
job file to achieve this (it needs a lot of testing-- see the description in
the job file). To test:
1. save the job as /etc/init/apparmor.conf
2. disable the click-apparmor job with: sudo sh -c "echo manual >
/etc/init/click-apparmor.override"
3. disable the network-interface-security job with: sudo sh -c "echo manual >
/etc/init/network-interface-security.override"
+ 4. add 'exit 0' to the top of /etc/init.d/apparmor
This should actually slightly improve boot time since less shell code is
being run with the simplified policy load. 14.10 will also support
precompiling apparmor policy in kernel postinst and touch image
generation to ensure that the cache is available on first boot to
further improve (first) boot speeds.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1305108
Title:
please provide upstart job for apparmor
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1305108/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
