Control: tag -1 - patch
Control: user pkg-apparmor-t...@lists.alioth.debian.org
Control: usertag -1 new-profile
Hi,
Pat Parson wrote (04 Dec 2014 02:48:08 GMT) :
> /bin/ps does not have an apparmor profile.
> I have attached an apparmor profile to patch the package.
Thanks a lot! Here's an initial review. I suggest you ask for feedback
on the upstream AppArmor mailing-list too, as people there may detect
issues I would not notice :)
> # Last Modified: Mon Dec 1 10:10:30 2014
I don't think we want this line.
> #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.
Also, tunables/global already includes tunables/kernelvars, so we
don't need to include it ourselves here.
> #most ps functions available without the dac_override & dac_read_search
Please fix the indentation, and add a space between "#" and "most",
just in case #most becomes a parser directive some day (like #include).
> /bin/ps mr,
> @{PROC} r,
> @{PROC}@{pid}/attr/current r,
> @{PROC}@{pid}/cmdline r,
> @{PROC}@{pid}/environ r,
> @{PROC}@{pid}/stat r,
> @{PROC}@{pid}/status r,
> @{PROC}@{pid}/task/ r,
> @{PROC}@{pid}/task/*/* r,
> @{PROC}@{pid}/wchan r,
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.
Opinions, anyone?
> @{PROC}tty/drivers r,
I wonder if this should go into the consoles abstraction.
What do Ubuntu/upstream folks think?
[Until this (very good initial) patch is polished, reviewed by more
people, and includes the needed packaging updates too, I'm dropping
the "patch" tag.]
Cheers,
--
intrigeri
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
