[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [redhat-lspp] auditing under lspp



On Wednesday 21 September 2005 10:58, Steve Grubb wrote:
> Hello,
> 
> I am trying to work out how the audit rules will be specified for LSPP 
> requirements. There are  several situations that I think we should go over.
> 
> 1) Does it make sense to allow auditing by type?
> 
> auditctl -a entry,always -F type=etc_t
> 
> 2) auditing by category/compartment?
> 
> auditctl -a entry,always -F cat=c0
> 
> 3) auditing by level?
> 
> auditctl -a entry,always -F level=s0
> 
> or ranges
> 
> auditctl -a entry,always -F level>s5
> auditctl -a entry,always -F level=s2-s5
> 
> 4) auditing by SE Linux users:
> 
> auditctl -a entry,always -F sel-user=system_u
> 
> 5) auditing by kernel keys
> 
> auditctl key -t user -r keyring -u uid -r role -t type

So -t user and -t, seems a little ambiguous :)?

> 
> 6) auditing by network address or protocol (RBAC-FAU_SEL.1a)
> 
> auditctl net -f family -p proto -a addr
> 
> 7) We still have the big issue of what actually does the MAC auditing. Should 
> these checks be done by the audit system or by SE Linux internals? If 
> internals, how do we insert/list/delete rules for mac auditing? It would seem 
> to be more efficient perhaps to do it in the SE Linux internals.
> 
> Thanks,
> -Steve
> 

Hi.

More of a general suggestion.. should we introduce long opts?  As it stands right
now, the more advanced auditctl becomes the less intuitive the command line
options become.  Not only are we running out of useful letters, we're also using
both lower and upper case characters to delineate opts.  To make matters worse
we're now (or so it seems) introducing opt namespaces... ACK!!!!!!!  

Way to confusing.  This is why I think we should introduce long opts.  When a user
types "man auditctl" they should then see something like --filter (-F) and instantly 
know what -F does and be given the option to use --filter, so there command line
argument, if they so choose, looks sane and readable.  And besides, for a robust
tool, it almost seems mandatory that long opt support is there.

-tim


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]