RE: file contexts and modularity

[Casey Schaufler <casey@xxxxxxxxxxxxxxxx>]

--- Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:

> This is something that I think merits further
> discussion.  I think that
> the real problem is that the avtab size has grown
> far beyond what we
> originally anticipated and this is hurting us both
> in time (to
> manipulate policies, to load policies, and even to
> search the avtab) and
> in space (kernel memory consumption by the avtab is
> huge).  We certainly
> didn't expect the avtab to reach 484,677 distinct
> entries (FC4 strict
> policy) and even the targeted policy in FC4 is now
> up to 215886 entries.

With close to half a million (Ack!) rules you
end up with a memory burden that would be
excessive even if you could represent a rule in
a single byte. Oh sure, you could swap out rule
pages on a LRU scheme, or hash them to death,
but the basic problem is not the representation
of hundreds of thousands of rules, it's a matter
of having hundreds of thousands of rules. Good
heavens, the policy file is starting to look
like the IRS tax code.

The solution does not lie in the direction
of kernel hacking, as much fun as that is.

Why are there so many rules? You can correct
me if I'm wrong, but these (somewhat jaded)
eyes see a piecemeal approach to the
introduction of new rules. There is serious
effort going into defining policies that
match behavior and since there are so many
different behaviors there is an explosion of
rules required to match them.

I suggest that if you want to address this
issue properly you need to back away from the
current method of developing policy.

Design your policy, then implement it rather
than sniffing out what programs do and then
crafting a policy to accomodate their whims.
I suggest you begin with a policy that includes
exactly two domains, User and System. Create
the rule set that provides this two state level
of protection. If a policy with two domains is
too stiffling use more, but define them first.

I don't believe that this is an easy path,
nor would I expect it to be popular. On the
other hand I guarantee you'll reduce the size
of the policy by a factor of 10. I also opine
that the actual system vulnerability will
decline due to better understanding of the
policy. I will also help address some of the
issues floating about regarding 3rd party
policy creation, what with having a designed
policy that a developer can follow instead
of the notion of "run strace and audit and
do magic".

It's what we had to do to create Unix MLS
systems. The casualty rate wasn't too high,
although it's true that we didn't get invited
to lots of partys afterward. Oh well, y'all
knew the job was dangerous when you took it.



Casey Schaufler
casey@xxxxxxxxxxxxxxxx


		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.