[apparmor] [patch] Change aa-logprof and aa-mergeprof to read the severity from CapabilityRule
steve at nxnw.org
Tue Jun 2 00:16:39 UTC 2015
On Sun, May 31, 2015 at 06:25:26PM +0200, Christian Boltz wrote:
> Am Freitag, 29. Mai 2015 schrieb Steve Beattie:
> > On Sun, May 24, 2015 at 06:53:35PM +0200, Christian Boltz wrote:
> > > Note: the != '--' check in aa-mergeprof is superfluous for
> > > capabilities, but will become useful once this code block is used
> > > for other rule types.
> > >
> > >
> > > [ 21-read-severity-from-capability-rule.diff ]
> > Again, I like everything here except for the magic value '--' that
> > is yet another representation of 'unknown value'
> Yes, but it also shows the difference between '--' and 'unknown':
> - 'unknown' (or whatever you tell severity.py to use for unknown)
> will display "Severity: unknown" in aa-logprof
> - '--' means "_not to display_ the "Severity:" line in aa-logprof
> It's pointless to do always display "Severity: unknown" for network
> rules (because we don't have severity rating for them). OTOH, displaying
> "Severity: unknown" for a file rule is more valueable because we have
> ratings for some files.
So what does exposing our failure to implement our guessed severity
values for certain classes of rules gain our users? We don't explain
anywhere why sometimes the Severity field shows up and sometimes it
does not. What does the extra complexity of our implementation gain,
including in an ideal world, the extra tests needed to know whether
we display the Severity field at the correct time or not?
To me it either makes sense to tell the user that we don't know the
severity of the event every time or never, not on arbitrary occasions
that are seemingly random to the user unless they either know or
guess our implementation's insufficiencies.
And even if we wanted to burble up "unimplemented" as a status rather
than "unknown", using a magic string that is not even a constant
defined somewhere strikes me as not the best way to do that.
<sbeattie at ubuntu.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the AppArmor