Re: Direction of the mailing list/effort

caseyat_private

Stephen Smalley wrote:

> 1) ... if you want a truly
> generic solution, it makes more sense to convert the SELinux and/or
> RSBAC interface to meet Linus' style than to start from scratch and
> have to re-argue about every hook.

I couldn't disagree more. Back in '86 AT&T (who owned UNIX)
at the time made a proposal that a version of ACLs they had
concocted be accepted as a /usr/group standard. The group
had many issues with the proposal, and even the technical
representitive from AT&T agreed that the proposal would require
serious revision. The Management representitive from AT&T
then said "I realize that there is some disagreement on
some of the details, but I propose that we adopt this
as the standard. We can always change it later."

Just as it was then, it's a really bad idea to start
from an implementation that is not universally approved of
and try to wedge goodness into it. The reasons why I
don't care for selinux or RSBAC are not relevent, it's
the assumption that they're within a "small" delta of
correct that I don't buy.

> 2) Linus said that he would be willing to entertain the notion
> of a large number of hooks in the kernel (he mentioned the number
> 140 without objection in his first message, and 200 in his
> second message).  That suggests that rather than being minimalist
> in developing our set of hooks, we can indeed take the set of
> code insertion points in existing systems like SELinux and RSBAC
> and define hooks based on them.  That allows us to provide
> comprehensive and flexible security and lets us leverage
> all of the prior research and development that has already
> gone into SELinux and RSBAC.

Don't forget other popular policies, including the No Checks
policy, Bell & LaPadula, Biba, NT (no endorsement implied),
and no-SUperUser-capabilties. Most importantly, the "new"
scheme should be built out from the existing framework. The
SELinux and RSBAC schemes are much more implementation models
than security policies. 

> 3) Linus also said that he would be willing to accept security IDs
> into a number of kernel data structures. Security IDs, if you're not
> familiar, are a policy-independent data type for security labels
> already used in SELinux.  We already know what data structures need
> security IDs for SELinux, since it is already implemented.  RSBAC
> used a different approach (using separate mappings for binding
> labels to subjects and objects), but they could probably easily
> generate a list of the data structures they would like to be able
> to directly tag.

There are many issues associated with "security IDs", including
performance, exportability, and persistance. I favor keeping
real security attribute information to the indirection usually
required of security ID schemes. Mapping IDs to security data
is a major problem in application space. Of course, if IDs refer
to data with actually identifies the security information,
that's fine. My understanding is that that's not the case
for SELinux.

> Based on Linus' message, I would think that the natural way to respond
> would be for projects like RSBAC and SELinux (and possibly others) to
> (preferably cooperatively but if necessary competitively) define the
> set of hooks that they would need based on their current code
> insertion points and to move their existing implementations behind
> these new hook interfaces.

I agree. The issue is the starting point.

> Since both RSBAC and SELinux are already
> quite general, I doubt that we would have any problem with
> implementing POSIX.1e capabilities, LIDS, LOMAC, SubDomain, CryptoMark
> and other schemes behind those same hooks.

You have always argued in the past that RSBAC is too
different from SELinux for their approaches to be useful
to SELinux. I recall in particular issues against the
wrapper approach.

> This approach will produce
> a truly generic solution that is both flexible and secure and that can
> satisfy all of the projects.  There is no reason to think that Linus
> will reject it, since he has expressed a willingness to consider a
> large number of hooks and since he wants a truly generic solution.

I do not believe that SELinux or RSBAC is a good starting point.
I believe that the first "module" should be Linux as it is today.
I believe that the second module should be "No Access Checks".
I believe that the third module should be Pure Posix Capabilities.
After that, anything goes to recommend extension to the mechanism.

-- 

Casey Schaufler				Manager, Trust Technology, SGI
caseyat_private				voice: 650.933.1634
casey_pat_private			Pager: 888.220.0607

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module