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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
