This profile was somewhat based upon feedback from upstream upon
another profile.
Steve Beattie<st...@nxnw.org> wrote:
" A better rule would probably be:
@{PROC}/@{pid}/loginuid r, "
An unexpected new compiler directive could cause a problem I agree. I
would prefer @{pid} to be capitalized and it is a little troublesome
where an * would suffice IMHO :)
Okay, since Wheezy and Jessie conflict on the includes & tunables,
then we need to either
1) leave those out if there are conflicts
2) create separate versioned profiles
3) create profiles for Jessie only
Which is the option I should persue?
You suggest that we just add a blanket whitelist with code such as
@{PROC}** r perhaps?
Pat
On 12/6/14, intrigeri <intrig...@debian.org> wrote:
> 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
