[pkg-apparmor] Bug#771978: Patch: apparmor profile for ps

[Craig Small]

I have tested this with ps and it seems that all the flags are working
OK. I couldn't break it with the usual combination of ps options.

On Sat, Dec 06, 2014 at 11:17:02AM +0100, intrigeri wrote:
> > #include <tunables/kernelvars>
> > #include <tunables/sys>
> These two last lines require AppArmor from Jessie, so the "Suggests:
> apparmor" that will be added to the ps package needs to be versioned
> for better partial upgrades support.
Is that required, or is it a case of if you want apparmor you load it.
I would of thought this would be the same as, say, logcheck where you
ship logcheck files and its up to the admin to install logcheck
themselves.

I needed to remove the kernelvars include for it to work, otherwise
I get a duplicate definition of pid errors. 

> I'm not sure if it makes sense, long-term wise, to whitelist what we
> want to allow in @{PROC}@{pid}. My concern is about the maintenance
> costs, when the kernel adds new interfaces in there, and ps learns how
> to use it, and then this profile has to learn about it.
We (upstream procps) would certainly be changing this around from time
to time.  I couldn't really tell you how often we do change the type of
files we access.  An added complexity is that a lot of the file loading
happens in the libprocps* library package and not the procps binary
package.

This is one of those balancing acts. The apparmor side of things should
have a better idea of where the usual balance is.

I also saw things like:
# for hostdev
/sys/devices/ r,
/sys/devices/** r,
Should these use the @{sys} just like the @{PROC} ?

 - Craig

-- 
Craig Small (@smallsees)   http://enc.com.au/       csmall at : enc.com.au
Debian GNU/Linux           http://www.debian.org/   csmall at : debian.org
GPG fingerprint:        5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5