--- Joshua Brindle <[EMAIL PROTECTED]> wrote:
> Casey Schaufler wrote:
> > --- Joshua Brindle <[EMAIL PROTECTED]> wrote:
> >
> >
> >> Casey Schaufler wrote:
> >> <snip>
> >>
> >>> Smack provides mandatory access controls based on the label attached
> >>> to a task and the label attached to the object it is attempting to
> >>> access. Smack labels are deliberately short (1-7 characters) text
> >>> strings. Single character labels using special characters are reserved
> >>> for system use. The only operation applied to Smack labels is equality
> >>> comparison. No wildcards or expressions, regular or otherwise, are
> >>> used.
> >>>
> >>> A file always gets the Smack label of the task that created it.
> >>>
> >>> Smack defines and uses these labels:
> >>>
> >>> "*" - pronounced "star"
> >>> "_" - pronounced "floor"
> >>> "^" - pronounced "hat"
> >>> "?" - pronounced "huh"
> >>>
> >>> The access rules enforced by Smack are, in order:
> >>>
> >>> 1. Any access requested by a task labeled "*" is denied.
> >>> 2. A read or execute access requested by a task labeled "^"
> >>> is permitted.
> >>> 3. A read or execute access requested on an object labeled "_"
> >>> is permitted.
> >>> 4. Any access requested on an object labeled "*" is permitted.
> >>> 5. Any access requested by a task on an object with the same
> >>> label is permitted.
> >>> 6. Any access requested that is explicitly defined in the loaded
> >>> rule set is permitted.
> >>> 7. Any other access is denied.
> >>>
> >>> Rules may be explicitly defined by writing subject,object,access
> >>> triples to /smack/load.
> >>>
> >>> Smack rule sets can be easily defined that describe Bell&LaPadula
> >>> sensitivity, Biba integrity, and a variety of interesting
> >>> configurations. Smack rule sets can be modified on the fly to
> >>> accomodate changes in the operating environment or even the time
> >>> of day.
> >>>
> >>>
> >>>
> >> How exactly can you describe a blp policy with this module?
> >>
> >
> > Example below. Actually, you chose the absolute worst case example
> > in a fully populated Bell&LaPadula sensitivity scheme. But real
> > world experiance is that MLS systems very rarely use both levels
> > and categories. A small number use just levels, which could be
> > represented thus:
> >
> > TS:SBI TS rx
> > TS:SBI S rx
> > TS:SBI C rx
> > TS:SBI U rx
> > TS S rx
> > TS C rx
> > TS U rx
> > S C rx
> > S U rx
> > C U rx
> >
> >
>
> Disregarding the belief some of us hold about the usefulness of a blp
> policy in general(*),
Yeah, I was a little bit surprized by this particular question
coming from you.
> the capabilities you are providing with this
> security module and the surrounding infrastructure make the situation
> worse.
Oh dear.
> It appears that users can only have 1 label each,
Today's implementation of sshd is a hack, just enough to get
things going. Longer term I expect users to have a list of
labels they can use. sshd currently uses /etc/smack/user,
which contains lines like:
method manic
casey loony
with future support for:
method manic madness acting
casey loony toons you bet
where each of the labels listed are available for login.
I've be concentrating on the kernel side for a number of
reasons, but I certainly am aware that the I&A side needs
to be addressed.
> there is no facility for changing labels of your user session, etc.
I do have a hackish newsmack command, which I should probably include.
All it does is write the new label to /proc/self/attr/current and
exec the desired program. That's not good enough for a production
system because of the well known pty, tty, and open files issues,
but fine for development purposes.
> I respect your intention to make this as minimal as possible but
> I just don't see anyone ever using it as is.
Smack is definitly still emphasizing the "early" of "release early".
I wouldn't ship it to a paying customer as is, to be sure.
> * blp is useful in some situations, I'll grant. One of those (few)
> situations is a CMW. Neglecting whether or not a CMW's are a good idea
HeeHee. Did you ever get to see the original Mitre CMW prototype?
The shell was a privileged program so that they could prevent the
window markings from changing every time it printed the prompt.
> anyway your system won't be able to create an effective CMW due to the
> lack of infrastructure
I can read this several ways, but I think the short answer is that
it's not that the infrastructure can't be there, but it's not there
now.
> including trusted X support,
Well shooot, SELinux ain't got that yet.
And I have done Trusted X on a system with B&L+Biba.
And should the support come in for SELinux, converting it over to Smack
doesn't look that overwhelming.
> multiple simultaneous user session labels, etc.
Not all CMW's had that.
> It wouldn't even be able to be a
> multilevel fileserver without labeled nfs support.
All Smack requires for NFS is xattr support. I've already posted a
worked example implementation of that. It would not be hard to
get that working, although I keep hoping someone will beat me to it.
> So, I'll repeat my
> question, do you have any *actual* use cases where this will solve an
> *actual* security problem.
Well, *actually*, yes. Even with the the whacked sshd being the only
way to log on to the system, no X windows, no NFS, no user crontabs,
and ptys not working right simple separation is the solution for 2 out
of 3 of the worlds existing MLS installations. Sorry, I can't name
names.
> > and the majority use just categories, which requires no specification
> > at all to provide separation.
> >
> >
>
> Except it won't provide real dominance relationships so everyone will be
> able to access their own category only.
Which is exactly what they *actually* ask for.
> This is obviously non-ideal, not
> in the spirit of category systems and again, not useful.
I don't understand how this is not ideal, out of the spirit, or not useful.
>
> >> How do you
> >> define dominance relationships between levels and over categories
> >> without a very complex policy?
> >>
> >
> > It's simple, but to do the full permutation set, not small.
> >
> >
> That is silly.
Everyone has a worst case, and a full permutation of B&L is Smack's.
Hey wait a minute! You hate B&L! You say it's fundimentally useless.
Why should I get my knickers in a twist over a useless case?
> In those terms SELinux is simple (allow foo_t bar_t :
> file read). It is only a tiny bit more verbose than your language and
> provides object class granularity, yet everyone claims SELinux is
> complex because of the policy size, the same goes for your statement above.
> > Let's say we want TS, S, and U for levels, with
> > categories A and B. The specification would be:
> >
> > TS/A,B TS/A rx
> > <snip>
> > S U rx
> >
> > I'm not saying that the preceeding is pretty, but it isn't complicated.
> >
> >
>
> Yes, and the policy gets exponentially worse every time you add a level
> or category, not an ideal situation for supposedly "simple" MLS
> implementations.
Yup. Again. *actual* MLS experiance is levels or categories, not both.
And you don't believe in MLS anyway.
> >> My main concern is that I don't see any real security goals or use cases
> >> that this can address, can you provide some use cases that make this a
> >> viable security mechanism?
> >>
> >
> > Well, there's Bell and LaPadula in the common category usage, the
> > occasional level usage, and the rare full level+cats scheme.
> >
> > Biba integrity is easy as well, just scroll back to the example and
> > turn your monitor upside down.
> >
>
> I am seriously dubious about the ability for this module to provide a
> working system with a Biba policy, but maybe thats just me :)
That's just you. Biba is pretty easy.
> > Another serious use is time based policy:
> >
> > at 5pm:
> >
> > # echo 'worker game x' > /smack/load
> >
> > at 8am:
> >
> > # echo 'worker game -' > /smack/load
> >
> > Those are simple examples of some of the more obvious uses.
> >
>
> Its a possibly interesting use case. I'm curious about this kind of
> 'overriding' of rules though, how does one see the currently effective
> policy?
# cat /smack/load
Thank you for the comments. They're helpful.
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
