Casey Schaufler wrote:
--- Joshua Brindle <[EMAIL PROTECTED]> wrote:
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.
The SELinux part is going to be a profile on top of the generic part so
there shouldn't be any conflicts in the implementation.
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.
Great, this was exactly what I was looking for. On the guard
implementation I'd like to note that assured pipelines are pretty hard
to get right. Without object class and create granularity (at the very
least) you might find it very difficult to control backflow. Consider
that 1) many IPC mechanisms in Linux have pretty big back channels, like
process B being able to pull X number of bits off a unix stream socket
and A being able to discover how much he pulled off. Also note
bitmap-style attacks where A can create lots of blocking IPC's and B can
go through and unblock the ones that he wants to be an 'on' bit.
We have a paper on this you should read,
http://selinux-symposium.org/2007/papers/11-SecureIPC.pdf
The solution in SELinux was to allow only a small, trusted helper app to
create the message queue (only 1) to avoid the bitmap attack so the only
overt back channel left is a very low bandwidth 'pop per time period'
style attack. We've gone through alot of effort to figure out how to
minimize the back channels in assured pipelines and still offer some
reasonable functionality, you'd probably benefit from the work we've
done on this topic.
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.
No, I'm much more satisfied now, IMO when you submit the patchset for
inclusion you should include use cases that will make sense to the
people reviewing the patch, that will show the possible uses for this patch.
-
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
