Activity log for bug #1305108

Date Who What changed Old value New value Message
2014-04-09 14:37:42 Jamie Strandboge bug added bug
2014-04-09 14:37:42 Jamie Strandboge attachment added apparmor.conf_v1 https://bugs.launchpad.net/bugs/1305108/+attachment/4077391/+files/apparmor.conf_v1
2014-04-09 14:45:54 Jamie Strandboge information type Public Public Security
2014-04-09 16:10:34 Jamie Strandboge bug added subscriber Steve Langasek
2014-04-09 16:11:36 Jamie Strandboge bug added subscriber Adam Conrad
2014-04-09 16:11:49 Jamie Strandboge bug added subscriber Dimitri John Ledkov
2014-04-09 16:13:57 Jamie Strandboge nominated for series Ubuntu Trusty
2014-04-09 16:13:57 Jamie Strandboge bug task added apparmor (Ubuntu Trusty)
2014-04-09 16:13:57 Jamie Strandboge nominated for series Ubuntu U-series
2014-04-09 16:13:57 Jamie Strandboge bug task added apparmor (Ubuntu U-series)
2014-04-09 16:14:05 Jamie Strandboge apparmor (Ubuntu U-series): status New Confirmed
2014-04-09 16:14:12 Jamie Strandboge apparmor (Ubuntu Trusty): status Confirmed New
2014-04-09 16:15:08 Jamie Strandboge description 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" 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. 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.
2014-04-17 18:50:26 Jamie Strandboge apparmor (Ubuntu Trusty): status New Triaged
2014-04-17 18:50:30 Jamie Strandboge apparmor (Ubuntu U-series): status Confirmed Triaged
2014-06-09 13:37:40 Jamie Strandboge apparmor (Ubuntu Trusty): status Triaged Won't Fix
2014-06-09 13:37:46 Jamie Strandboge apparmor (Ubuntu Utopic): importance Undecided High
2014-06-09 13:37:53 Jamie Strandboge tags rtm14
2014-06-09 13:38:05 Jamie Strandboge tags rtm14 application-confinement rtm14
2014-06-17 18:42:44 Marc Deslauriers attachment added apparmor.conf_v2 https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1305108/+attachment/4133516/+files/apparmor.conf_v2
2014-06-23 19:22:25 Launchpad Janitor branch linked lp:ubuntu/utopic-proposed/apparmor
2014-06-23 19:42:58 Launchpad Janitor apparmor (Ubuntu Utopic): status Triaged Fix Released
2017-01-18 17:28:28 Launchpad Janitor apparmor (Ubuntu Trusty): status Won't Fix Fix Released