Re: [RFC] [PATCH]
On Thu, 2006-02-16 at 14:09 -0600, Darrel Goeddel wrote:
True on role dominance. No on constraint_expr_eval - I'll give
it a look.
Note that we'd still want separate audit representation (so that we
don't expose the constraint representation directly to audit), but could
convert it to constraint form during rule setup and then just feed it to
constraint_expr_eval or some common helper.
I'll add some comments for that. A rule will get reprocessed
when a new
policy is loaded (triggered by the seqno check in security_aurule_match).
That will then reset the au_skip field appropriately. The idea behind this
is to allow a rule to be present for a type, role, etc. that does not exist
in the current policy, but they are never processed. If the item is included
in a policy that is loaded later, the rule will be setup completely and
activated (au_skip = 0). Conversely, if an item disappears, the rule is
just inactivated.
This give the same behavior as the other audit rule fields. For example, a
rule can be there for a uid that is not used on the system and it will simply
never match. If that uid is later used on the system, the rule will then be
used. Same goes for inums that aren't used and probably most other fields...
True, but seems prone to error, e.g. user typo on a name or user using
an obsolete name never knows he made a mistake. Unless auditctl itself
does validity checking, which requires it to interact with
libsemanage/libsepol.
--
Stephen Smalley
National Security Agency