Re: Linux Security *Module* Framework (Was: LSM conversion to static interface

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface

[Adam Jerome]

On Wed, Oct 24, 2007 at  6:55 AM, Adrian Bunk <bunk@kernel.org> wrote: 
> On Wed, Oct 24, 2007 at 12:50:29PM +0100, Simon Arlott wrote:
>> I currently have an LSM that only handles permissions for socket_bind
>> and socket_listen, I load it and then "capability" as secondary on
>> boot - but now I can't because the LSM framework is now just the LS
>> framework.
>> 
>> Why can't this "static LSM" change be a Kconfig option?
>> (I don't want to have to maintain my own reverted copy of security/,
>> or compile this into the kernel because then I can't ever modify and
>> reload it without rebooting.)
> 
> Let's start with the more important questions:
> 
> Did you submit your LSM for inclusion into the kernel?
> 
> If yes, why wasn't it accepted?
> If no, why not?

Those are important questions, no doubt.  However, that does not
address Simon's question.  Especially in light of Linus' statement:

 "I'm also perfectly willing to unapply it if there actually are
  valid out-of-tree users that people push for not merging."

It seems that, whether submitted (and or accepted) into the kernel
or not, Simon has the obligation to respond to Linus' challenge.

-adam

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface

[Crispin Cowan]

Tetsuo Handa wrote:
> I think there are two other problems regarding LSM.
>
> (1) There is only one "struct security_ops" structure in the system.
>
> (2) There is only one "void *security" field in "struct task_struct".
>
>
> Years ago, there was only one MAC implementation (i.e. SELinux)
> in the mainline kernel.
> But now, there are many MAC (or access control/tracking) implementations
> waiting for inclusion into the mainline kernel.
> The competition for occupying "struct security_ops" has started.
>
> My idea is that, why not create chains of "struct security_ops"
> (i.e. linked list of "struct security_ops")
> and allow choosing which chain to use for per a "struct task_struct" basis
> (i.e. add "struct security_ops" to "struct task_struct").
>   
That idea was in the Stacker module, and it was tabled until there is
more than one upstream LSM. In particular, it requires 2 or more LSMs
that actually make sense to stack together. IMHO TOMOYO/AppArmor/SELinux
are all exclusive of one another (in a running kernel) and real stacking
is still pending useful component intrusion prevention modules. Such
modules can be built, they just have not yet been built.

> TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use
> "struct security_ops" since SELinux is occupying it.
>   
Just disable SELinux and load TOMOYO. Oh, you can't because someone has
made modules not be loadable :(  Hmmm, perhaps someone could fix that by
reverting the static interface patch ... :)

> May be we should consider stackable LSM again?
>   
Exactly. Stacker was shelved, so to speak :) because of the lack of
in-kernel modules. Soon it will be time to reconsider that.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
CEO, Mercenary Linux		   http://mercenarylinux.com/
	       Itanium. Vista. GPLv3. Complexity at work

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface

[Tetsuo Handa]

Hello.

Simon Arlott wrote:
> I currently have an LSM that only handles permissions for socket_bind
> and socket_listen, I load it and then "capability" as secondary on
> boot - but now I can't because the LSM framework is now just the LS
> framework.

I think there are two other problems regarding LSM.

(1) There is only one "struct security_ops" structure in the system.

(2) There is only one "void *security" field in "struct task_struct".


Years ago, there was only one MAC implementation (i.e. SELinux)
in the mainline kernel.
But now, there are many MAC (or access control/tracking) implementations
waiting for inclusion into the mainline kernel.
The competition for occupying "struct security_ops" has started.

My idea is that, why not create chains of "struct security_ops"
(i.e. linked list of "struct security_ops")
and allow choosing which chain to use for per a "struct task_struct" basis
(i.e. add "struct security_ops" to "struct task_struct").

TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use
"struct security_ops" since SELinux is occupying it.
Yes, there is secondary_ops in SELinux, but it doesn't help TOMOYO Linux
since SELinux is not calling secondary ops for operations TOMOYO Linux wants to control.
So, there is only one "struct security_ops" as a matter of practice.


At the same time, the competition for occupying "void *security" has started.

My idea is that, why not allow multiple "void *security" fields in "struct task_struct"?

TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use
"struct task_struct"->security field since SELinux is occupying it.
If TOMOYO Linux is permitted to add "void *" and "u32" to "struct task_struct",
SELinux and other LSM implementations can use "struct task_struct"->security field.


May be we should consider stackable LSM again?

Regards.

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface

[Adrian Bunk]

On Wed, Oct 24, 2007 at 12:50:29PM +0100, Simon Arlott wrote:
> I currently have an LSM that only handles permissions for socket_bind
> and socket_listen, I load it and then "capability" as secondary on
> boot - but now I can't because the LSM framework is now just the LS
> framework.
> 
> Why can't this "static LSM" change be a Kconfig option?
> (I don't want to have to maintain my own reverted copy of security/,
> or compile this into the kernel because then I can't ever modify and
> reload it without rebooting.)

Let's start with the more important questions:

Did you submit your LSM for inclusion into the kernel?

If yes, why wasn't it accepted?
If no, why not?

> Simon Arlott

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Linux Security *Module* Framework (Was: LSM conversion to static interface

[Simon Arlott]

I currently have an LSM that only handles permissions for socket_bind
and socket_listen, I load it and then "capability" as secondary on
boot - but now I can't because the LSM framework is now just the LS
framework.

Why can't this "static LSM" change be a Kconfig option?
(I don't want to have to maintain my own reverted copy of security/,
or compile this into the kernel because then I can't ever modify and
reload it without rebooting.)

-- 
Simon Arlott