[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dazuko-devel] 2.3.5-pre1 (patch) posted

From: John Ogness
Subject: Re: [Dazuko-devel] 2.3.5-pre1 (patch) posted
Date: Wed, 26 Mar 2008 20:59:38 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix)

On 2008-03-24, jim burns <address@hidden> wrote:
> I could easily do with out selinux personally, but I suspect I would
> not always have that option when working for other people.
> So I'm thinking out loud about solutions:
> [...]
> 2) Some kernel patch to allow all three functions to be active at the same 
> time. Is there such a beast?

Since all three modules would work together without any technical
problems, this is probably the most feasible. However, it will involve
patching SElinux code and I'm not sure if we want to do that. The nice
thing about the current patch is that it doesn't touch any other
code. That is good because SElinux and Capabilities go through
extensive security audits that would be meaningless if they were

Another possible option may be to create a very simple stacker LSM
module that _only_ supports SElinux, Dazuko and Capabilities. By
having the stacker module load first, it could support all three. A
generic stacker module has been attempted in the past (and failed)
because it becomes too messy if multiple modules share the same
hooks. But if we _only_ support SElinux, Dazuko, and Capabilities,
there would be no problem.

(Although I must admit I would not look forward to creating a module
that allows SElinux to stack. This is a big job because SElinux grabs
a lot of hooks and these would need to be carefully verified with each
new kernel release.)

(And now that I think about it, SElinux will only load if it is the
primary module. So even this method would require touching SElinux

> 3) Your patch did give me an idea about a simple patch to security/Kconfig. 
> Change:
>         bool "Default Linux Capabilities"
> back to:
>         tristate "Default Linux Capabilities"
> so you can once again select 'm' for module in kernel configuration.

This won't work (as you later found out) because the LSM API is not
available to kernel modules. LSM modules _must_ be built statically.

> Any other ideas?

Another option would be to hook the syscall table instead of using
LSM. Since it is a kernel patch (rather than a module), this would be
quite simple. But I hate even bringing up this option as it is heavily
looked down upon by the kernel community. I really would like to stay
with LSM until DazukoFS is ready.

John Ogness

Dazuko Maintainer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]