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

Re: SELinux Context Label based audit filtering

On Fri, 2006-02-03 at 12:44 -0500, Stephen Smalley wrote:
> Having some email difficulties from my usual address, so to quickly
> respond to your questions off-list:

'When at first you don't succeed, try Gmail' :)  Words to live by.

> 1) MLS level/range translation is already config-file based, see
> setrans.conf in /etc/selinux/$SELINUXTYPE/setrans.conf (where
> SELINUXTYPE is the policy type defined in /etc/selinux/config). 
> libsetrans is what reads that file and provides interfaces for
> translating contexts.  libselinux uses libsetrans if present to
> translate all contexts entering or exiting its interfaces to provide
> transparent translation to applications, but in your case, you are
> doing explicit translation of specific fields, so you likely want
> direct libsetrans interfaces.

I see now.  This sounds like a sound, sane, easily-configurable approach.

> 2) My point about the delayed asking for contexts for SIDs was simply
> that under the proposed scheme, you don't pre-generate the contexts
> and attach them to the audit context; you only save the SIDs in it,
> and then only generate full contexts if all filters pass and you
> decide to generate an audit message.  But that could be an issue since
> allocation could then fail for the context.

And carrying around these SIDs as opposed to the string contexts should
provide enough of an efficiency benefit to merit reworking it as you

> 3) I might be wrong about being able to completely avoid allocation
> and copying for the user/role/type strings, because of the policy
> reload issue; the old val_to_name arrays would be destroyed upon a
> policy reload.  So we might need to perform allocation and copying of
> those (small) strings.

Ok, so requesting from SELinux the individual user or role or type
string as opposed to getting the entire label and having audit slice and
dice it up?  If that's what you mean, I may be able to salvage a good
bit of my patch, which would be nice.

> 4) Not sure about how much time I have to dive into this; I can work
> on it some, but I have a constant flow of patches coming my way to
> deal with over on selinux list, and I also have a lot of meetings next
> week (unfortunately), so I'm hesitant to put myself on the critical
> path for this (but in the end, I may have to).

Ok, I understand.  I think Steve was going to talk to James Morris to
see if he has any cycles.  Otherwise, I'll start looking into it on
Monday.  I'm just afraid that in the time it will take you and others to
review my code for these new SElinux api's, you might have been able to
write better api's anyway.


Attachment: signature.asc
Description: This is a digitally signed message part

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