Dear, Sir,
Thanks for your response and I'm very sorry for my late response.
Firstly, I have to introduce myself. I'm trying to promote SELinux in
Japan from 2002 (almost 5-years.....). And I started up SELinux
SI/training/support business in my company from 2005.
#Also, I'm a member or LIDS develop team and promoting LIDS in Japan:-p
Actually, I like SELinux(or TE) concept. Label-based-security concept is
more intuitively than path-based-secrity.
Belows are just my feeling, not logically.
(So, Please, please don't flame me.)
Label-based-security is like a "paintball". If we could mark to
objcet correctly, we can easily point object
like "blue-color-man", "red-color-man" or something.
Path-based-security is more depend on circumstance,
like "man on that tree", "man in that bush" or something.
But, still SELinux is too complicated. Many of technical materials
are recommending to disable SELinux because it provide
"too constrain" system.
(I know latest SELinux on Fedora or RHEL5 is more easy to use.
But many of system administrators don't want to use Fedora or
latest distribution for stable system.)
Then, I think we have two options as below;
1.) make SELinux better
2.) make other "security mechanism" (easy, or not easy, doesn't matter)
I know many of SELinux developers are choosing option 1.).
But, we can't stop other developers to choose option 2.), right?
In my point of view, some of SELinux developers are trying to say
"don't choose 2.)" to all of developers.
Also, I still wonder who decide to put new LSM security module
to mainline. Past year, some of security module put their patch
to LSM-ML, right?
- PitBull Foundation and LX (I know PitBull have a long histry)
- AppArmor
- Digsig
- UidBind
- MultiAdmin
- SLIM
- file capabilities :-)
etc.
Why we still don't have new LSM security module? Who makes decision?
Sincerely,
OMO
Casey Schaufler wrote: (2007/06/27 00:42):
--- "Kazuki Omo(Company)" <[EMAIL PROTECTED]> wrote:
Folks,
May I ask some foolish questions?
So long as you're not afraid of foolish answers.
I just want to make sure what do we need
if we want to put new security module(which is using LSM) in mainline.
1. Does it have to provide complete "MAC" which Casey Schaufler
explained in below mail?
http://marc.info/?l=linux-kernel&m=118252843017261&w=2
No. Your mechanism can be descretionary if you like. It can be
based on user IDs, phase of the moon, or any other scheme you
like. The arguments you've seen claiming that a module should not
go upstream because the mechanism is incomplete go against the
spirit of the LSM and should be ignored.
2. Does it have to provide any solution which SELinux can't cover?
HeeHee. There do appear to be some SELinux zealots out there, don't
there? No. Overlap between your module and SELinux is irrelevent.
SELinux is one security scheme, and it is intended to cover all
possible cases.
3. Do we have to proof the new security module "can't" implement
as policy on SELinux?
Well, it wouldn't hurt. But look at what happened in the AppArmor
argument. First, AppArmor claimed to do something that SELinux
couldn't do. The SELinux Zealot response was that SELinux could
do that. The AppArmor crowd requested demonstration. The Zealots
spent a couple days hacking something up, and presented it. This
bit of hackery was heavily criticized from several fronts. The
Zealots then used this criticizm to say that this proved that the
problem was with the underlying premise of AppArmor.
Don't expect it to be easy and don't expect all the arguments to
follow traditional rules of debate. Finally, if you prove that you
have something truely unique that SELinux can't do, expect to be
told that no one would want that anyway.
4. Does it have to provide complete security feature from beginning?
Can we implement just small features to mainline and develop
new features in same time?
Release early and often, but come in with enough so that it's
clear what you intend to do, why what you have is special, and
what impact it might have on the rest of the system. AppArmor's
big problem is the changes required to the vfs layer. It would
be very difficult to get the natives so worked up about AppArmor
if it was an LSM that required no external changes.
5. Does it have to have any Security model which documented/evaluated
in academic conference?
I certainly hope not. One of the intentions of LSM, at least early
on, was to encourage new and inovative models. I can understand
how it might seem otherwise given some of the recent debates.
I saw LSM-ML past 1 year and sometime I saw
"You should try and get your code into mainline".
But, anytime many people were discussing about above points and
I think nobody put anything in mainline
(Now I'm checking 2.6.21 kernel and I couldn't find any
security module except "Default Linux Capabilities", "Root Plug", and
"SELinux").
That's correct. As your questions lead the reader to summize, there
is a faction that does not want any more LSMs. Some members of the
community would be happy for LSM to be abandoned and SELinux adopted
as the Linux security infrastructure. These people often point to the
fact that there are no other LSMs to back their position. They also
work to make the notion of presenting an LSM for consideration
frightening, and as your message here indicates, have had no small
success.
Not everyone associated with SELinux exhibits these behaviors, and
there is definitly anti-SELinux zeal in the community, too. No one
gets defensive if they've never been attacked, after all.
My suggestion? Make sure your LSM is so clean it squeeks. Provide
as much information about what it does and why it's good as you
can. Can SELinux do the same thing? Maybe, but so what? Let the
zealots prove it. Either way thank them for their input and move on.
It may take years to get your LSM upstream, it certainly took
SELinux a while, and the version that got in bears very little
resemblence to what they first proposed.
Best of luck, and thank you for making the effort.
Casey Schaufler
[EMAIL PROTECTED]
--
Kazuki Omo: [EMAIL PROTECTED]
Group Manager, OSS Technology Center
Diary: http://omok.livejournal.com
-
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
