"Serge E. Hallyn" <[email protected]> writes:
> Quoting Eric W. Biederman ([email protected]):
>>
>> Perform the split up you talked about above and move the table
>> matching into the LSM hooks.
>>
>> Use something like the iptables action and match to module mapping
>> code so we can have multiple modules compiled in and useable at the
>> same time with the LSM hooks.
>>
>> I think it is firmly established that selling SElinux to everyone is
>> politically untenable. However enhancing the LSM (even if it is
>> mostly selinux code movement down a layer) I think can be sold.
>>
>> If I could run Serge's isolation code and selinux rules at the same
>> time that would be interesting.
>
> But given that namespaces are making it upstream, what else is to be
> gained from the bsdail module? What exactly are you looking for?
Good question. I keep tripping over the LSM hooks, and I have the
distinct impression that part of the current contention and lack of
agreement is simply the way things are current factored. So I'm
putting for a constructive suggestion that has the possibility of
going somewhere.
> 1. are you looking to cover all the corner cases - i.e. prevent killing
> a process in another namespace through F_SETOWN or mqueue, etc?
I'm looking towards this yes. There are times when we deliberately
allow mixing of things by the definition of what namespaces are and
there are some use cases where people don't want this.
> 2. are you looking for a potentially easier fix to the current absence
> of isolation in the user namespace?
No. I'm not even worrying about the user namespace until it resembles
complete. Currently I just view it as a stub because as is, the
security namespace is pretty much useless for any case I think about.
We still have way to many cases where the kernel treats different
names as the same name.
> 3. are you just generally looking to make lsm/selinux easier for
> yourself to configure?
Well. I'm trying to make the LSM more useful to hack on and configure,
and much less contentions for ordinary people to use.
There is one issue with sockets that has come up where there are
people who really want to filter things at connect and bind time.
The LSM is so inflexible the only sane suggestion at the time was
to duplicate the LSM hooks and add an new iptable style table
for making that decision.
Also I'm thinking towards what do we have to do isolate the security
module stuff in the context of a namespace. So that a person in
a container can setup their own rules that further restrict the
system.
So far I'm not ready to do anything yet but I'm keeping a weather eye
on the situation so I have a clue what I'm go.
> If 1, an selinux policy should cover you. So you can then skip to 3.
> Or, alternatively, I do plan - as soon as my free time clears up a bit -
> on demonstrating how to write some selinux policy to create a secure
> container based on current -mm + your experimental network namespace
> patches.
Thanks that sounds interesting.
> If 3, then selinux policy modules may actually help you, else either
> a new LSM (maybe like LIDS) or a userspace tool which is a front-end to
> selinux policy, emulating the iptables rules formats, may be what you
> want?
I don't want to have to choose my LSM at compile time. I want to
add support into the kernel at compile time and be able to configure
it before I go multi-user. I know this kind of architecture is
achievable because iptables allows it.
When I conceive as the security modules as just a firewall between
applications on my own box I think, oh yeah this is no big deal,
I might want to limit something that way some time. These are just
some additional rules on when to return -EPERM. So I ask myself why
is this situation much less flexible and much harder to use then our
network firewall code?
>> My impression is that selinux is one monolithic blob that doesn't
>> allow me to incrementally add matching or action features that I
>> find interesting.
>
> Actually with policy modules it gets much much better. I have in fact
> been able to pretty easily write a short policy module to, say, create
> an selinux user which ran as root and had full access to the system to
> do system setup for automated testing. There is a learning curve in
> having to look at existing modules for maybe a few days to get started,
> but once you get started the policy modules do make it very easy to
> add to current policy.
Ok. Interesting. Are these kernel modules?
Still while I get the general impression that selinux seems to be
very close to a generic solution, and that selinux more or less has
the architecture we might want. I don't get the impression that
selinux does this at a level that is open to other people doing
interesting things.
So I still ask the question can we move this functionality down to
the LSM in a way that will solve the composition problem between
multiple security modules?
It really seems to me that the LSM as currently structured creates
a large barrier to entry for people who have just this little thing
they want to do that is not possible with any existing security
module.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
