--- Joshua Brindle <[EMAIL PROTECTED]> wrote:
> Casey Schaufler wrote:
> > ...
> >
> > 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.
> >
>
> Right, I'd like to see how you solve those problems :)
Me too. Especially with devpts "out of bounds". I have some ideas,
but I don't know whether they're good ones yet.
> >> 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.
> >
> >
> Great, I'd like to note that I'm not being a naysayer, I'm merely
> interested in the use cases that this module can address, which I
> believe is a legitimate question.
You betcha.
> >> * 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.
> >
>
> welll... just because someone did it doesn't make it good :)
CMW would have been a dandy, 20years ahead of it's time application
suite. As an OS spec, well...
> >> 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.
> >
> ah! I wasn't comparing this to SELinux,
Neither was I. Mirely pointing out that the current industry
leader is short on this one as well.
> I was saying that a proper CMW
> needs this and, if you follow my premises, smack can implement blp, blp
> is primarily useful for things like CMW's.
I see. Well, yes, you could use Smack as a CMW base, in which case
you need a whole pile of stuff on top. Honestly, I don't see CMW as
a viable target for an OS because it would be so much better done as
an application with today's technology.
> There is, at least, an
> implementation of Trusted X for SELinux though, just not in a distro, yet.
Excellect. My work's at least half done then.
> > 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.
> >
> >
> Right, that means more infrastructure to query your security server,
> like SELinux' userspace object manager interface. I suppose this will be
> upcoming?
Yeah, although I confess to still being in the goofy scheme phase.
I feel strongly about keeping the application infrastructure light
and simple, so don't expect it to invoke interpretors anywhere.
> >> 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.
> >
> >
> Well good, since there is a generic NFS labeling RFC going around it
> might be interesting to see how it works for you.
I also see an effort that's SELinux specific. Should be fun.
> >> 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.
> >
> >
> note the question was about use cases, not installations that you can't
> talk about, which isn't exactly helpful.
The use of categories to keep projects apart is a very common case.
Smack handles this trivially. In this case users would log in with
their assigned smack labels and work as usual (assuming I get the
pty, cron, cups, email, ... details worked out) while being isolated
from the users of the system with other labels.
A strictly heirarchical scheme, where TS can read S and U, S can read U,
is less common but still seen from time to time. This is very much like
the category scheme, except that read access is granted labels of
higher sensitivity to those of lower sensitivity.
A case that Bell&LaPadula does not allow that Smack does:
ESPN ABC r
ABC ESPN r
On my portable video device I have two applications, one that
shows ABC programming and the other ESPN programming. ESPN wants
to show me sport stories that show up as news, and ABC will
only provide minimal information about a sports story if ESPN
is covering it. Each side can look at the other's info, neither
can change the other. Neither can see what FOX is up to, which
is just as well all things considered.
Another case that I especially like:
SatData Guard w
Guard Publish w
A program running with the Guard label opens a UDP socket and
accepts messages sent by a program running with a SatData label.
The Guard program inspects the message to ensure it is wholesome
and if it is sends it to a program running with the Publish label.
This program then puts the information passed in an appropriate
place. Note that the Guard program cannot write to a Publish
file system object because file system semanitic require read as
well as write.
> Once again, I'm not saying this isn't useful or doesn't do what it says,
> I'm just interested in the actual use cases for it, if you show use
> cases I'd be fine with this modules existence. :)
The four cases (categories, levels, mutual read, guardbox) here
are all quite real, and problems I've been asked to solve over
the years. The first two are easy to do with traditonal MLS systems
while the last two you can't without invoking privilege, at least
for a while.
I hope to have sample implementations of some other facilities as
well once I get the more agregeous of the kernel shortcomings
taken care of.
Thank you again for your comments. Let me know where I'm still
coming up short on the explainations.
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
