2:51 p.m.
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
propose?
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.
:-Dustin
3:14 p.m.
New subject: SELinux Context Label based audit filtering
On Fri, 2006-02-03 at 14:51 -0600, Dustin Kirkland wrote:
And carrying around these SIDs as opposed to the string contexts
should
provide enough of an efficiency benefit to merit reworking it as you
propose?
Carrying the SIDs gives you the option of passing them to SELinux so
that it can immediately look up the context structure and perform
comparisons, extract values, etc w/o needing to re-parse the context
string. But you may still need to carry the context strings to avoid
allocation failures at the end when it is too late to abort the
operation.
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.
Given that we need to precompute a MLS context struct when the audit
filter rule is inserted anyway (so that we can later do efficient
comparisons of MLS levels), we might want to do this for all of the
fields, eliminating string comparisons entirely at audit filter
evaluation time. See my description of the step-by-step approach for
the MLS case in my earlier response to Steve.
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.
Possibly, but that doesn't create a larger pool of people who can
contribute in the future to the project...
--
Stephen Smalley
National Security Agency
4:34 p.m.
New subject: SELinux Context Label based audit filtering
On Fri, 2006-02-03 at 16:14 -0500, Stephen Smalley wrote:
Carrying the SIDs gives you the option of passing them to SELinux so
that it can immediately look up the context structure and perform
comparisons, extract values, etc w/o needing to re-parse the context
string. But you may still need to carry the context strings to avoid
allocation failures at the end when it is too late to abort the
operation.
Gotcha. I'll continue carrying the context strings to avoid eventual
allocation failures for the time being.
Given that we need to precompute a MLS context struct when the audit
filter rule is inserted anyway (so that we can later do efficient
comparisons of MLS levels), we might want to do this for all of the
fields, eliminating string comparisons entirely at audit filter
evaluation time. See my description of the step-by-step approach for
the MLS case in my earlier response to Steve.
Ok, I'm going to work though your 9-step program early next week.
Possibly, but that doesn't create a larger pool of people who
can
contribute in the future to the project...
Understood. Investment in the future ;)
:-Dustin
7:34 a.m.
New subject: SELinux Context Label based audit filtering
On Fri, 2006-02-03 at 16:34 -0600, Dustin Kirkland wrote:
On Fri, 2006-02-03 at 16:14 -0500, Stephen Smalley wrote:
> Carrying the SIDs gives you the option of passing them to SELinux so
> that it can immediately look up the context structure and perform
> comparisons, extract values, etc w/o needing to re-parse the context
> string. But you may still need to carry the context strings to avoid
> allocation failures at the end when it is too late to abort the
> operation.
Gotcha. I'll continue carrying the context strings to avoid eventual
allocation failures for the time being.
The other option of course is to just accept that we might fail on that
allocation (as there are other potential failure cases at the same
point), log what we can (e.g. the SIDs), and call audit_panic. That
saves us the overhead of always allocating and generating those context
strings when we don't need them.
--
Stephen Smalley
National Security Agency
6840
days inactive
6843
days old
linux-audit@lists.linux-audit.osci.io
3 comments
2 participants
participants (2)
-
Dustin Kirkland -
Stephen Smalley