Casey Schaufler wrote:
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.

ok, fair enough.

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.


Right, I'd like to see how you solve those problems :)

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.

* 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 :)

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, 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. There is, at least, an implementation of Trusted X for SELinux though, just not in a distro, 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.
Right, that means more infrastructure to query your security server, like SELinux' userspace object manager interface. I suppose this will be upcoming?

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.

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.

<snip>

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. :)

-
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

Reply via email to