Re: LSM conversion to static interface

Re: LSM conversion to static interface

[Thomas Fricaccia]

Yes, I think Crispin has succinctly summed it up:  irrevocably closing
the LSM prevents commercial customers from using security modules other
than that provided by their Linux distributor.  As Sarbanes-Oxley and
other regulatory laws require these customers to use "standard
kernels", the result is a rather dreary form of vendor lock-in, where the
security framework is coupled to the distribution.

Though it would require a somewhat undesirable complexity of CONFIG_
flags, it should be possible to construct flexibility enough for everyone
to get what he wants.  For example, it should be possible to configure
kernels with a single security framework hard-linked, AND it should
also be possible to configure kernels such that the default security
framework could be completely replaced at boot time by another, be it
out-of-tree module, or other.

I agree entirely that preserving this form of freedom for the end user
makes Linux a much stronger technology than not.  For one thing, the
consequences of closing LSM are fairly certain to irritate enterprise
commercial customers, which is probably a sign that the technology has
taken a wrong turn.

Tommy F.


Crispin Cowan <crispin@crispincowan.com> wrote:

> So the net impact of this patch is:
> 
>    * It takes a deployment practice (static compiled-in security) that
>      is arguably good in many circumstances and makes it mandatory at
>      all times.
>    * It takes a development practice that is very convenient and
>      slightly risky, and forces you into the pessimal inconvenient
>      development practice at all times.
>    * It prevents enterprise users, and in fact anyone who isn't
>      comfortable compiling their own kernel, from ever trying out any
>      security module that their distro vendor of choice did not ship.
>
> This strikes me as a rather anti-choice position to take. It says that
> because candy is bad for you, you only ever get to eat vegetables. I
> don't understand why Linux would want to do this to its users.
>
> It doesn't hurt me or AppArmor. Since AppArmor is now shipping with
> SUSE, Ubuntu, and Mandriva, what this does is make it harder for newer
> modules like TOMOYO, Multi-Admin, etc, to get exposure to enterprise
> users. So I don't think I am being self-serving in arguing against this
> patch. I just think it is bad for Linux.
>
> Crispin
>
> -- 
> Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
>         Itanium. Vista. GPLv3. Complexity at work

Re: LSM conversion to static interface

[Greg KH]

On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
> the LSM prevents commercial customers from using security modules other
> than that provided by their Linux distributor.

Any "customer" using a security model other than provided by their Linux
distributor instantly voided all support from that distro by doing that.

So, since the support is gone, they can easily build their own kernels,
with their own LSM interfaces, and get the exact same lack of support :)

And, what are these "other LSM modules" you speak of that people rely on
to run their businesses?

> As Sarbanes-Oxley and
> other regulatory laws require these customers to use "standard
> kernels", the result is a rather dreary form of vendor lock-in, where the
> security framework is coupled to the distribution.

Wait, what?

Since when does Sarbanes-Oxley decree that a company must use a
"standard kernel"?  And just exactly what defines such "standard
kernel"?  Can you point out where in that bill it requires such a thing?

Totally confused,

greg k-h

Re: LSM conversion to static interface

[Alan Cox]

On Sun, 21 Oct 2007 19:24:42 -0700
"Thomas Fricaccia" <thomas_fricacci@yahoo.com> wrote:

> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
> the LSM prevents commercial customers from using security modules other
> than that provided by their Linux distributor.  As Sarbanes-Oxley and
> other regulatory laws require these customers to use "standard
> kernels", the result is a rather dreary form of vendor lock-in, where the
> security framework is coupled to the distribution.

Crispin at least is providing genuine discussion points. Sarbox has
nothing to say on "using vendor linux kernels".

Re: LSM conversion to static interface

[Crispin Cowan]

Alan Cox wrote:
> On Sun, 21 Oct 2007 19:24:42 -0700
> "Thomas Fricaccia" <thomas_fricacci@yahoo.com> wrote
>> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
>> the LSM prevents commercial customers from using security modules other
>> than that provided by their Linux distributor.  As Sarbanes-Oxley and
>> other regulatory laws require these customers to use "standard
>> kernels", the result is a rather dreary form of vendor lock-in, where the
>> security framework is coupled to the distribution.
>>     
> Crispin at least is providing genuine discussion points. Sarbox has
> nothing to say on "using vendor linux kernels".
>   
I agree that SarBox is not really the issue here. Partially related is
enterprise rules about what kernels one is allowed to load. More
generally, this change forces users who want to use a different LSM than
their vendor provides to recompile their kernel, where they did not have
to recompile before. It forces LSM module developers who want to modify
their LSM to reboot, where they didn't necessarily have to reboot before.

That is not a catastrophe, it is just tedious. It does not kill baby
seals, and it does not make Linux utterly useless. OTOH, I think it is
strictly negative: it takes away user choice in 2 dimensions, and adds
zero value. So apply it if you must to bake the kernel developer's lives
easier, but it really is a net loss in Linux kernel capability.

Crispin

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

Re: LSM conversion to static interface

[Alan Cox]

> > Crispin at least is providing genuine discussion points. Sarbox has
> > nothing to say on "using vendor linux kernels".
> >   
> I agree that SarBox is not really the issue here. Partially related is
> enterprise rules about what kernels one is allowed to load. More
> generally, this change forces users who want to use a different LSM than
> their vendor provides to recompile their kernel, where they did not have
> to recompile before. It forces LSM module developers who want to modify
> their LSM to reboot, where they didn't necessarily have to reboot before.

The moment they load a module from a third party they usually hit support
issues, unless there is some kind of arrangement between the parties.

> 
> That is not a catastrophe, it is just tedious. It does not kill baby
> seals, and it does not make Linux utterly useless. OTOH, I think it is
> strictly negative: it takes away user choice in 2 dimensions, and adds
> zero value. So apply it if you must to bake the kernel developer's lives
> easier, but it really is a net loss in Linux kernel capability.

Frankly I don't care about apparmor, I don't see it as a serious project.
Smack is kind of neat but looks like a nicer way to specify selinux rules.

What I do care about is that at some point something is going to appear
which is based on all the same good practice and experience and forty
years of research that leads towards SELinux, and which is much better. At
that point there will be a changeover phase and the LSM is exactly what
is needed for this.

The fact it allows people to play with toy security systems, propose new
ones like SMACK, and do research and PhD work on Linux into security is a
convenient and very good side effect.

For that reason I think keeping LSM is the right thing to do.

Alan

Re: LSM conversion to static interface

[Greg KH]

On Mon, Oct 22, 2007 at 05:50:43PM +0100, Alan Cox wrote:
> 
> For that reason I think keeping LSM is the right thing to do.

Wait, we aren't talking about dropping LSM at all, just the "LSM is a
module" option.  That's it.  And by making LSM not a module, we can then
go on to fix some of the reported speed issues that are present with the
LSM option enabled right now.

thanks,

greg k-h

Re: LSM conversion to static interface

[Avi Kivity]

Greg KH wrote:
> On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
>   
>> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
>> the LSM prevents commercial customers from using security modules other
>> than that provided by their Linux distributor.
>>     
>
> Any "customer" using a security model other than provided by their Linux
> distributor instantly voided all support from that distro by doing that.
>
> So, since the support is gone, they can easily build their own kernels,
> with their own LSM interfaces, and get the exact same lack of support :)
>
>   

Running a vendor kernel has the advantage of reusing all the QA work 
that has gone into that kernel.  It is very different from running 
2.6.24-rc1 (or 2.6.22.x).  Hence projects like centos: you don't get any 
support, but the likelihood of actually requiring support is lower than 
running some random kernel.

[but I agree that someone who has somehow determined that they need a 
specific LSM will probably have determined that they need vendor support 
as well]

-- 
error compiling committee.c: too many arguments to function

Re: LSM conversion to static interface

[Adrian Bunk]

On Mon, Oct 22, 2007 at 07:47:36PM +0200, Avi Kivity wrote:
> Greg KH wrote:
>> On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
>>   
>>> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
>>> the LSM prevents commercial customers from using security modules other
>>> than that provided by their Linux distributor.
>>>     
>>
>> Any "customer" using a security model other than provided by their Linux
>> distributor instantly voided all support from that distro by doing that.
>>
>> So, since the support is gone, they can easily build their own kernels,
>> with their own LSM interfaces, and get the exact same lack of support :)
>
> Running a vendor kernel has the advantage of reusing all the QA work that 
> has gone into that kernel.  It is very different from running 2.6.24-rc1 
> (or 2.6.22.x).  Hence projects like centos: you don't get any support, but 
> the likelihood of actually requiring support is lower than running some 
> random kernel.

You can also get the QA work by building your own kernel from vendor 
kernel sources.

E.g. the Debian distribution ships a package linux-source-2.6.18 that 
contains a linux-source-2.6.18.tar.bz2 with the patched 2.6.18 kernel 
sources Debian uses for building its kernels.

> [but I agree that someone who has somehow determined that they need a 
> specific LSM will probably have determined that they need vendor support as 
> well]

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

Re: LSM conversion to static interface

[Geert Uytterhoeven]

On Sun, 21 Oct 2007, Greg KH wrote:
> On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
> > As Sarbanes-Oxley and
> > other regulatory laws require these customers to use "standard
> > kernels", the result is a rather dreary form of vendor lock-in, where the
> > security framework is coupled to the distribution.
> 
> Wait, what?
> 
> Since when does Sarbanes-Oxley decree that a company must use a
> "standard kernel"?  And just exactly what defines such "standard
> kernel"?  Can you point out where in that bill it requires such a thing?

Simple, these days Sarbanes-Oxley is the default argument behind anything being
pushed down your throat in a company.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: LSM conversion to static interface

[Samir Bellabes]

Jan Engelhardt <jengelh@computergmbh.de> writes:

> Which reminded me of the TuxGuardian LSM[1] - another of the real-world 
> uses to meet Linus's criteria? ("had examples of their real-world use to 
> step forward and explain their use")
>
> In this specific project, LSM is used to collect up calls to bind() and 
> connect() and pass them to userspace, e.g. do it ZoneAlarm-style and 
> display a dialog window. Its codebase is probably not too up-to-date 
> (website says last change last April - but I guess that's a no-brainer 
> to update it).
>
> [1] http://tuxguardian.sf.net/

It's not exactly true, tuxguardian is only dealing with .socket_create
and .socket_listen from the struct security_operations, and not
socket_bind

I have done some work in this area since last year, and mailed the
netdev list about it. [1]

the project is 'network events connector' [2]. It's using the LSM
hooks to get interesting informations from syscalls, to push them to
userpace. So differences between projects will be on features and the
code itself.

Before getting a more infos on the project, as a 'LSM user', my main
concern is not that we can unload/load dynamically the security modules,
or have to reboot to do that. I don't have any point on this.

My point is more that the 'user' have to be able to choose which system
is better for him, and by 'user' we can hear linux distros. If
security's modules don't do the same thing, we have to accept to have
multiple modules, ie for example 'the 'network event connector' as a
personnal firewall, and why not another security module for checking 
filesystem. Whitout this approach, tools like mine are pointless for 
linux distros, because there are already working on SELinux, Appamor,
etc.. Not thinking this, is to think that on day, we will have the
perfect and standard security module, but this won't happen, because
users don't want the same thing: "I only want a personnal firewall at
first place, and not a entire role based model".

Now here is more infos on the project, so if not interested so you can
escape now :)

A/ for features:
1/ more hooks
static struct security_operations snet_security_ops = {
        .socket_create          = snet_socket_create,
        .socket_bind            = snet_socket_bind,
        .socket_connect         = snet_socket_connect,
        .socket_listen          = snet_socket_listen,
        .socket_accept          = snet_socket_accept,     
        .socket_post_accept     = snet_socket_post_accept,
        .socket_sendmsg         = snet_socket_sendmsg,
        .socket_recvmsg         = snet_socket_recvmsg,     
        .socket_sock_rcv_skb    = snet_socket_sock_rcv_skb,
};

2/ global control
the main idea behind tuxguardian is preventing rootkit applications 
to execute listen(), so it's warning userspace.

This is really interesting, but I think we can do more than just
that. We can allow in a simple/dynamical way such iptables rules :

iptables -A INPUT -i ppp0 -p tcp -m tcp --dport 22 --syn -m state --state NEW -j ACCEPT 

just by detecting the sys_listen() call which has been execute by sshd,
and for example only by /usr/bin/sshd (path name based) or 'sshd' role
group (ie SELinux approach), and let packets coming from the network for
this socket to bypass the firewall (of course the user/admin is
controlling it from the userspace).

But we also can control the sys_connect() dynamically from userspace for
example, and prevent application using connect(), regarding the
destination IP address/port, protocol, uid, application (and why not
time, etc).

The main problem and interesting part is the sys_accept(), because only
the LSM hook socket_accept can make the syscall failling. But what
could be interesting is to block/accept the syscall regarding the
remote socket informations (ie which IP address is connecting ?). And
this approch is not possible with the socket_accept hook (it comes too
early) 

Tomoyo tried to solve this by moving the security_socket_post_accept()
before the fd_install() [3]. This is bad for at least two reasons: 
 - this hook was historically not added for this kind of filtering [4]
 - we already have a netfilter tool to help us: libnetfilter_queue [5]

The idea is to send informations about the sys_listen() syscall,
so inform the userspace that a application is maybe waiting for
packets, then using libnetfilter_queue, check packets that match the
socket involved on the sys_listen(). If we have such packet, we can ask
the user to accept or deny this packets.
This approach don't require a modification in the LSM architecture, and 
it's better to use netfilter to deal with packets.

B/ for the code itself:
1/
I'm moving the code from the netlink connector to use generic
netlink/libnl. Tuxguardian is using sock_sendmsg/sock_recvmsg directly

2/
for receiving answers from userspace (I call that "verdict"),
tuxguardian is using sock_recvmsg(), so there is no timeout. I'm using
waitqueue and timers for each "events" sent and "verdict". I'm calling a
event the couple (protocol, syscall) for example (TCP, connect).

there is a documentation/information here [2]. I'm planning to release
next version with genetlink and updated docs on the next week.

thanks,
sam

[1] http://www.spinics.net/lists/netdev/msg24437.html
[2] http://www.synack.fr/project/cn_net/cn_net.html

[3] http://www.mail-archive.com/linux-security-module@vger.kernel.org/msg01393.html

--- linux-2.6.orig/net/socket.c 2007-10-02 11:11:51.000000000 +0900
+++ linux-2.6/net/socket.c      2007-10-02 11:26:23.000000000 +0900
@@ -1434,13 +1434,16 @@ asmlinkage long sys_accept(int fd, struc
                        goto out_fd;
        }
 
+       /* Filter connections from unwanted peers like TCP Wrapper. */
+       err = security_socket_post_accept(sock, newsock);
+       if (err)
+               goto out_fd;
+
        /* File flags are not inherited via accept() unlike another
        OSes. */
 
        fd_install(newfd, newfile);
        err = newfd;
 
-       security_socket_post_accept(sock, newsock);
-
 out_put:
        fput_light(sock->file, fput_needed);
 out:

[4] http://copilotconsulting.com/mail-archives/security-module.2002/msg00186.html
[5] http://www.netfilter.org/projects/libnetfilter_queue/index.html

Re: LSM conversion to static interface

[Jan Engelhardt]

As I read through LWN today, I noted the following comment, 
http://lwn.net/Articles/255832/ :

	Personally, I think it's absolutely essential to be able to 
	build a kernel with dynamic LSM. Whether we like it or not, 
	people do want to add in runtime loadable security modules for 
	things like virus scanners, and until upstream offers these 
	folks a viable alternative to LSM...well, they'll use it.

Which reminded me of the TuxGuardian LSM[1] - another of the real-world 
uses to meet Linus's criteria? ("had examples of their real-world use to 
step forward and explain their use")

In this specific project, LSM is used to collect up calls to bind() and 
connect() and pass them to userspace, e.g. do it ZoneAlarm-style and 
display a dialog window. Its codebase is probably not too up-to-date 
(website says last change last April - but I guess that's a no-brainer 
to update it).

[1] http://tuxguardian.sf.net/

Re: LSM conversion to static interface

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

On Tue, 23 Oct 2007 10:34:09 CDT, "Serge E. Hallyn" said:

> And he will still be able to *run* the suid binary, but if cap_bound is
> reduced he won't be able to use capabilities taken out of the bounding
> set, multiadm loaded or not.

I am willing to bet that there's still a *lot* of unaudited set[ug]id code
out there that's vulnerable to the same sorts of attacks as the one that
hit Sendmail a few back.  As such, I have to agree with your original
post of the patch that CAP_SYS_ADMIN should be required to lower the set,
as there's just too much danger of an exploit if users can create their
own reduced-set processes.

I'm debating whether we should have a printk if we detect that a removed
capability caused an -EPERM.  Yes, it can be used to spam the logs.  On the
other hand, I as the sysadmin would like to know if it's happening. Looks like
time for a sysctl or something....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: LSM conversion to static interface

[Greg KH]

On Tue, Oct 23, 2007 at 12:12:11AM -0700, Crispin Cowan wrote:
>     * Some people are not comfortable building kernels from source. It
>       doesn't matter how easy *you* think it is, it is a significant
>       barrier to entry for a lot of people. Especially if their day job
>       is systems or security administration, and not kernel hacking.

That's why I wrote a whole book about how to do just that.  And it's
free, print it out and give it to all your friends!
	www.kroah.com/lkn/

thanks,

greg k-h

Re: LSM conversion to static interface

[Serge E. Hallyn]

Quoting Jan Engelhardt (jengelh@computergmbh.de):
> 
> On Oct 23 2007 10:20, Serge E. Hallyn wrote:
> >
> >Once the per-process capability bounding set is accepted
> >(http://lkml.org/lkml/2007/10/3/315) you will be able to do something
> >like:
> >
> >	1. Create user 'jdoe' with uid 0
> 
> UID 0 is _not_ acceptable for me.

I'm aware.

> >	2. write a pam module which, when jdoe logs in, takes
> >	   CAP_NET_ADMIN out of his capability bounding set
> >	3. Now jdoe can log in with the kind of capabilities subset
> >	   you describe.
> 
> It is not that easy.
> CAP_DAC_OVERRIDE is given to the subadmin to bypass the pre-security
> checks in kernel code, and then the detailed implementation of
> limitation is done inside multiadm.

You mean the read/write split?

> This is not just raising or lowering capabilities.

Nope, but it's related, and as I pointed out below it fits in pretty
nicely.

> >It's not a perfect solution, since it doesn't allow jdoe any way at all
> >to directly execute a file with more caps (setuid and file capabilities
> >are subject to the capbound).  So there is certainly still a place for
> >multiadm.
> 
> A normal user can execute suid binaries today, and so can s/he with mtadm.
> I do not see where that will change - it does not need any caps atm.

And he will still be able to *run* the suid binary, but if cap_bound is
reduced he won't be able to use capabilities taken out of the bounding
set, multiadm loaded or not.

-serge

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 23 2007 10:20, Serge E. Hallyn wrote:
>
>Once the per-process capability bounding set is accepted
>(http://lkml.org/lkml/2007/10/3/315) you will be able to do something
>like:
>
>	1. Create user 'jdoe' with uid 0

UID 0 is _not_ acceptable for me.

>	2. write a pam module which, when jdoe logs in, takes
>	   CAP_NET_ADMIN out of his capability bounding set
>	3. Now jdoe can log in with the kind of capabilities subset
>	   you describe.

It is not that easy.
CAP_DAC_OVERRIDE is given to the subadmin to bypass the pre-security
checks in kernel code, and then the detailed implementation of
limitation is done inside multiadm.
This is not just raising or lowering capabilities.

>It's not a perfect solution, since it doesn't allow jdoe any way at all
>to directly execute a file with more caps (setuid and file capabilities
>are subject to the capbound).  So there is certainly still a place for
>multiadm.

A normal user can execute suid binaries today, and so can s/he with mtadm.
I do not see where that will change - it does not need any caps atm.

Re: LSM conversion to static interface

[Serge E. Hallyn]

Quoting Jan Engelhardt (jengelh@computergmbh.de):
> 
> On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
> >
> >> I do have a pseudo LSM called "multiadm" at 
> >> http://freshmeat.net/p/multiadm/ , quoting:
> >
> >> Policy is dead simple since it is based on UIDs. The UID ranges can be 
> >> set on module load time or during runtime (sysfs params). This LSM is 
> >> basically grants extra rights unlike most other LSMs[1], which is why 
> >> modprobe makes much more sense here. (It also does not have to do any 
> >> security labelling that would require it to be loaded at boot time 
> >> already.)
> >
> >But his is against LSM design (and first agreements about LSM):
> >LSM can deny rights, but it should not give extra permissions
> >or bypass standard unix permissions.
> 
> It is just not feasible to add ACLs to all million files in /home,
> also because ACLs are limited to around 25 entries.
> And it is obvious I do not want <prof> to have UID 0, because
> then you cannot distinguish who created what file.
> So the requirement to the task is to have unique UIDs.
> The next logical step would be to give capabilities to those UIDs.
> 
> *Is that wrong*? Who says that only UID 0 is allowed to have
> all 31 capability bits turned on, and that all non-UID 0 users
> need to have all 31 capability bits turned off?
> 
> So, we give caps to the subadmins (which is IMHO a natural task),
> and then, as per LSM design (wonder where that is written) deny
> some of the rights that the capabilities raised for subadmins grant,
> because that is obviously too much.

Once the per-process capability bounding set is accepted
(http://lkml.org/lkml/2007/10/3/315) you will be able to do something
like:

	1. Create user 'jdoe' with uid 0
	2. write a pam module which, when jdoe logs in, takes
	   CAP_NET_ADMIN out of his capability bounding set
	3. Now jdoe can log in with the kind of capabilities subset
	   you describe.

It's not a perfect solution, since it doesn't allow jdoe any way at all
to directly execute a file with more caps (setuid and file capabilities
are subject to the capbound).  So there is certainly still a place for
multiadm.

-serge

Re: LSM conversion to static interface

[Simon Arlott]

On Mon, October 22, 2007 18:13, Greg KH wrote:
> I agree, that is why customers do not load other random security modules
> in their kernel today, and why they will not do so tomorrow.  So,
> because of that, this whole point about compliance with regulatory law
> seems kind of moot :)
>
> Again, LSM isn't going away at all, this is just one config option for
> allowing LSM to work as a module that is changing.  If a customer
> demands that this feature come back, I'm sure that the big distros will
> be the first to push for it.  But currently, given that there are no
> known external LSMs being used by customers demanding support, I don't
> see what the big issue here really is.

I have an out of tree module to do per-port (tcp/udp) bind permissions,
it works fine with the "capability" module as secondary and I can load
or unload both of them at any time... this recent change completely
breaks that. (I had to #include dummy.c though).

Why should I now need to:
1. reboot every time I change the code when I could just reload modules before?
2. put it into my kernel source tree to use it?

-- 
Simon Arlott

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 23 2007 11:14, Giacomo A. Catenazzi wrote:
>> So, we give caps to the subadmins (which is IMHO a natural task),
>> and then, as per LSM design (wonder where that is written) deny
>> some of the rights that the capabilities raised for subadmins grant,
>> because that is obviously too much.
>
> Nothing wrong.  I only said that it was against (IIRC) the
> principle of LSM in kernel (we should only remove capacities).

Leave my capacitance alone! :)
[i hope you get the joke]

Anyway - I see your point. But what would give the user the capabilities
in the first place, if not a security module that implements this-and-that
capability-raising scheme?

Re: LSM conversion to static interface

[Giacomo A. Catenazzi]

Jan Engelhardt wrote:
> On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
>>> I do have a pseudo LSM called "multiadm" at 
>>> http://freshmeat.net/p/multiadm/ , quoting:
>>> Policy is dead simple since it is based on UIDs. The UID ranges can be 
>>> set on module load time or during runtime (sysfs params). This LSM is 
>>> basically grants extra rights unlike most other LSMs[1], which is why 
>>> modprobe makes much more sense here. (It also does not have to do any 
>>> security labelling that would require it to be loaded at boot time 
>>> already.)
>> But his is against LSM design (and first agreements about LSM):
>> LSM can deny rights, but it should not give extra permissions
>> or bypass standard unix permissions.
> 
> It is just not feasible to add ACLs to all million files in /home,
> also because ACLs are limited to around 25 entries.
> And it is obvious I do not want <prof> to have UID 0, because
> then you cannot distinguish who created what file.
> So the requirement to the task is to have unique UIDs.
> The next logical step would be to give capabilities to those UIDs.
> 
> *Is that wrong*? Who says that only UID 0 is allowed to have
> all 31 capability bits turned on, and that all non-UID 0 users
> need to have all 31 capability bits turned off?
> 
> So, we give caps to the subadmins (which is IMHO a natural task),
> and then, as per LSM design (wonder where that is written) deny
> some of the rights that the capabilities raised for subadmins grant,
> because that is obviously too much.

Nothing wrong.  I only said that it was against (IIRC) the
principle of LSM in kernel (we should only remove capacities).
I've nothing against the changing the design or rules.
It was only a commentary, to be sure that we know what we do ;-)

ciao
	cate

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 21 2007 08:57, James Morris wrote:
>> >I'd like to note that I asked people who were actually affected, and had 
>> >examples of their real-world use to step forward and explain their use, 
>> >and that I explicitly mentioned that this is something we can easily 
>> >re-visit.
[...]

I looked at commit 20510f2f4e2dabb0ff6c13901807627ec9452f98
[havenot done much kernel activity recently] where you
transform the security interface, and what I see is that
all the static inline functions are replaced by an extern one, with the
same content. That actually seems to include more performance hit
than the (un)registering fluff. Why is that, actually?

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
>
>> I do have a pseudo LSM called "multiadm" at 
>> http://freshmeat.net/p/multiadm/ , quoting:
>
>> Policy is dead simple since it is based on UIDs. The UID ranges can be 
>> set on module load time or during runtime (sysfs params). This LSM is 
>> basically grants extra rights unlike most other LSMs[1], which is why 
>> modprobe makes much more sense here. (It also does not have to do any 
>> security labelling that would require it to be loaded at boot time 
>> already.)
>
>But his is against LSM design (and first agreements about LSM):
>LSM can deny rights, but it should not give extra permissions
>or bypass standard unix permissions.

It is just not feasible to add ACLs to all million files in /home,
also because ACLs are limited to around 25 entries.
And it is obvious I do not want <prof> to have UID 0, because
then you cannot distinguish who created what file.
So the requirement to the task is to have unique UIDs.
The next logical step would be to give capabilities to those UIDs.

*Is that wrong*? Who says that only UID 0 is allowed to have
all 31 capability bits turned on, and that all non-UID 0 users
need to have all 31 capability bits turned off?

So, we give caps to the subadmins (which is IMHO a natural task),
and then, as per LSM design (wonder where that is written) deny
some of the rights that the capabilities raised for subadmins grant,
because that is obviously too much.

Re: LSM conversion to static interface

[Giacomo A. Catenazzi]

Crispin Cowan wrote:
> Giacomo Catenazzi wrote:
>> What do technical and regulatory differences have "driver/LSM module" that
>> is build-in and one that is modular?
>> It seems to me silly to find difference.  A kernel with a new kernel module
>> is a new kernel.
>>   
> *I* understand that, from a security and logic integrity point of view,
> there is not much difference between a rebuilt-from-source kernel, and a
> standard kernel from the distro with a new module loaded.
> 
> However, there is a big difference for other people, depending on their
> circumstances.
> 
>     * Some people live in organizations where the stock kernel is
>       required, even if you are allowed to load modules. That may not
>       make sense to you, but that doesn't change the rule.

[read also the very last commentary: don't take to seriously my
arguments]

ok, but why simplifying life of company with such silly rule?
Are not the same people that required commercial UNIX kernel?
So don't worry about internal company rules.  In one year a lot
of things changes.
Anyway it is a good motivation to delay the conversion, if there
are really so many external LSM modules used in production environment.
(but see next point)

>     * Some people are not comfortable building kernels from source. It
>       doesn't matter how easy *you* think it is, it is a significant
>       barrier to entry for a lot of people. Especially if their day job
>       is systems or security administration, and not kernel hacking.

Configuring a new kernel is not "kernel hacking" and IIRC is considered
in the very first level of LPI.

Anyway where you will find the new module?  It should be very specific
on the actual kernel installed.  I find few differences to distribute
a module or a kernel.  Distributions have/had a lot of kernels
(versions, SMP, processor specific, vserver, xen, readhat, clusteres, 
...), so why not distribute a new kernel?


 > Think of it like device drivers: Linux would be an enterprise
 > failure if you had to re-compile the kernel from source every
 > time you added a new kind of device and device driver.

This is a frequent argument, but I don't believe it ;-)
I see more time this argument that new devices on an enterprise.
The real argument is:
: Think of it like device drivers: Linux would be an enterprise
: failure if you had to *compile* the kernel from source for
: *every machine*.
Which is a good point to have modules.  Is it still a good point
to have LSM modules?  And to obey the "Sarbanes-Oxley"


Don't take me wrong, the above commentaries are not so serious,
and my point was not about modules, but why "Sarbanes-Oxley"
tell us that new modules are simpler then new kernel.

I like kernel without modules, so I want to understand all motivations
why people need modules (and this thread showed me other (non-classical)
reasons).  I know that the modules are necessary in most situation, but
I like to see if some reasons can be solved in other ways, so to
simplify also the life of "build-in" peoples.

ciao
	cate

Re: LSM conversion to static interface

[Crispin Cowan]

Giacomo Catenazzi wrote:
> What do technical and regulatory differences have "driver/LSM module" that
> is build-in and one that is modular?
> It seems to me silly to find difference.  A kernel with a new kernel module
> is a new kernel.
>   
*I* understand that, from a security and logic integrity point of view,
there is not much difference between a rebuilt-from-source kernel, and a
standard kernel from the distro with a new module loaded.

However, there is a big difference for other people, depending on their
circumstances.

    * Some people live in organizations where the stock kernel is
      required, even if you are allowed to load modules. That may not
      make sense to you, but that doesn't change the rule.
    * Some people are not comfortable building kernels from source. It
      doesn't matter how easy *you* think it is, it is a significant
      barrier to entry for a lot of people. Especially if their day job
      is systems or security administration, and not kernel hacking.

Think of it like device drivers: Linux would be an enterprise failure if
you had to re-compile the kernel from source every time you added a new
kind of device and device driver.

Crispin

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

Re: LSM conversion to static interface

[Giacomo Catenazzi]

Thomas Fricaccia wrote:
> Some well-respected contributors have taken exception my amplification
> of Crispin Cowan's point about the patch that closes LSM.
> 
> Crispin Cowan <crispin@crispincowan.com> wrote:
>>     * It prevents enterprise users, and in fact anyone who isn't
>>       comfortable compiling their own kernel, from ever trying out any
>>       security module that their distro vendor of choice did not ship.
> 
> I extended this point by observing that regulatory laws make it difficult
> for enterprise customers to compile their own kernels, mentioning one
> of the more invasive statutes, Sarbanes-Oxley.
> 
> In reply, "Alan Cox" <alan@lxorguk.ukuu.org.uk> writes:
>> Crispin at least is providing genuine discussion points. Sarbox has
>> nothing to say on "using vendor linux kernels".
> 
> And just previously, "Greg KH" <greg@kroah.com> had written:
>> Since when does Sarbanes-Oxley decree that a company must use a
>> "standard kernel"?  And just exactly what defines such "standard
>> kernel"?  Can you point out where in that bill it requires such a
>> thing?
> 
> I was actually talking about the *effects* of regulatory law, rather
> than the wording in the text of the statutes.  The misunderstanding
> could be partially my fault, as my exact words were 
> 
>    As Sarbanes-Oxley and other regulatory laws require these
>    customers to use "standard kernels" ....
> 
> which may not have been as unambiguously clear as I intended.
> 
> But as long as we're here, let me elaborate on the point I tried to make.
> 
> SOX and other laws require enterprise customers to keep specified
> controls on their internal processing procedures, and keep documentation
> that can be audited to prove compliance.  The auditing requirements
> are extensive and detailed, and certainly include the kernel of an
> operating system used to process business and/or financial transactions.
> 
> It is within this framework that enterprise customers conclude something
> like (and this is vernacular, not the language within the statutes) "if
> we use any kernel other than that supplied by our distributor, the
> SOX auditing paperwork will be a nightmare."  (I've actually heard
> statements similar to this, and so believe that it is an accurate
> portrayal of the perception of the effects of regulatory law.  I'm not
> a lawyer.)
> 
> As I said at the beginning, I meant to amplify Crispin's observation
> that enterprise customers are reluctant to compile their own kernels
> with the additional observation that the complexities of regulatory
> law create obstacles that are significant contributors to that reluctance.
> 
> I'll not belabor the unfortunate non sequitur further.  You can find
> plenty of documentation of auditing requirements with by Googling
> combinations of "Sarbanes-Oxley," "operating system integrity", etc.
> This is a big-business topic of wide concern.

What do technical and regulatory differences have "driver/LSM module" that
is build-in and one that is modular?
It seems to me silly to find difference.  A kernel with a new kernel module
is a new kernel.

ciao
	cate

Re: LSM conversion to static interface

[Giacomo Catenazzi]

Jan Engelhardt wrote:

> I do have a pseudo LSM called "multiadm" at 
> http://freshmeat.net/p/multiadm/ , quoting:

> Policy is dead simple since it is based on UIDs. The UID ranges can be 
> set on module load time or during runtime (sysfs params). This LSM is 
> basically grants extra rights unlike most other LSMs[1], which is why 
> modprobe makes much more sense here. (It also does not have to do any 
> security labelling that would require it to be loaded at boot time 
> already.)

But his is against LSM design (and first agreements about LSM):
LSM can deny rights, but it should not give extra permissions
or bypass standard unix permissions.

ciao
	cate

Re: LSM conversion to static interface

[david]

On Mon, 22 Oct 2007, Crispin Cowan wrote:

>
> Suffice it to say that there are a variety of reasons why someone either
> cannot re-compile a kernel, or just does not want to recompile a kernel.
> This change to LSM removes their choice to use modules others than those
> provided by their distro vendor.
>
one reason to not be willing to rebuild the kernel is that they may rely 
on a module from a different third party that is shipped/tested for the 
specific pre-compiled kernels from the distro.

David Lang

Re: LSM conversion to static interface

[Crispin Cowan]

Greg KH wrote:
> On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote:
>   
>> Security is big business, as is compliance with regulatory law.  Large
>> enterprise customers are NOT going to either void their system support
>> contracts, or place themselves in jeopardy of failing a SOX audit.
>>     
> I agree, that is why customers do not load other random security modules
> in their kernel today,
That "random" module could be a module supplied by a vendor other than
the distro supplier, such as a security vendor. It could be a research
prototype that the user wants to try out on their enterprise-supported
kernel. It could even be an in-house developed module that a local site
wants to run on his larger organization's blessed kernel.

So far from "random", these modules are motivated by circumstances
radically different than yours. In particular, rebuilding a kernel for
you (GregKH, many LKML developers) is a casual thing to be done before
breakfast, but is a scary obstacle to many others. It is an obstacle to
people who are skilled at computers but deliberately *not* kernel
developers (the whole world does not need to be a Linux kernel
developer) and it is an obstacle to large enterprise admins who have
organizational pressure to use specific, pre-built kernels.

>  and why they will not do so tomorrow.  So,
> because of that, this whole point about compliance with regulatory law
> seems kind of moot :)
>   
I think the specific stuff about regulatory compliance is tangential.
SarBox and friends don't specify Linux kernel versions, they are
incredibly vague and subject to interpretation. But they are part of
what drive organizations to have self-imposed rules about only running
blessed kernel versions.

Suffice it to say that there are a variety of reasons why someone either
cannot re-compile a kernel, or just does not want to recompile a kernel.
This change to LSM removes their choice to use modules others than those
provided by their distro vendor.

> Again, LSM isn't going away at all, this is just one config option for
> allowing LSM to work as a module that is changing.  If a customer
> demands that this feature come back, I'm sure that the big distros will
> be the first to push for it.  But currently, given that there are no
> known external LSMs being used by customers demanding support, I don't
> see what the big issue here really is.
>   
As I said, it is a medium issue, not a big one, which is why I didn't
speak out before.

I am opposed to this change because I see zero benefit to it, and a lot
of down-side in loss of user choice.

Because that is what this does: it does not help the kernel get better.
It *definitely* does not help the kernel become more secure. It mostly
just removes user's choice, by making it difficult to do things that
some people don't approve of.

As I've said, it doesn't hurt AppArmor, because 3 major distros ship it.
But it will hurt user choice and innovation, by making anything not
shipped by a distro more difficult to access.

There is some performance gains to be had by doing something to the LSM
interface. Certainly a configuration option that statically inlines all
the hooks and points them at a compiled in module would yield some
performance gain, but I don't know how much. But that raises 2 questions:

   1. Was *performance* really the reason this patch was proposed? Or
      was it because James really did want the restrictive effect of
      preventing people from choosing after-market modules and
      dynamically unloading them if they want? I believe that James was
      well-intentioned in trying to block these actions because he
      believes them to be insecure, and he's right, they are insecure.
      However, these actions are also very practically useful in many
      circumstances. I disagree with the change because an individual
      LSM can block both such actions if you wish, so imposing it on all
      LSM modules is restricting choice unnecessarily.
   2. Is the performance issue that this might address really big enough
      to bother fixing at all? Maybe, but I don't know. Again, I'm
      strictly opposed to the loss of flexibility until the performance
      issue is documented, and then I would rather see it be a
      configuration option you can choose to inline your module of
      choice, rather than the default behavior.

Crispin

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

Re: LSM conversion to static interface

[Greg KH]

On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote:
> To possibly save bandwidth, I'll also respond to another of Greg's points:
> 
> "Greg KH" <greg@kroah.com> wrote:
> > Any "customer" using a security model other than provided by their Linux
> > distributor instantly voided all support from that distro by doing that.
> 
> This isn't necessarily true.  In fact, I don't think it's even _remotely_
> likely to be typical.

But that is completly true _today_ and is the way that the "enterprise"
distros work.  Do you have any evidence of it not being the case?

> Security is big business, as is compliance with regulatory law.  Large
> enterprise customers are NOT going to either void their system support
> contracts, or place themselves in jeopardy of failing a SOX audit.

I agree, that is why customers do not load other random security modules
in their kernel today, and why they will not do so tomorrow.  So,
because of that, this whole point about compliance with regulatory law
seems kind of moot :)

Again, LSM isn't going away at all, this is just one config option for
allowing LSM to work as a module that is changing.  If a customer
demands that this feature come back, I'm sure that the big distros will
be the first to push for it.  But currently, given that there are no
known external LSMs being used by customers demanding support, I don't
see what the big issue here really is.

thanks,

greg k-h

Re: LSM conversion to static interface

[Alan Cox]

> The point of contention:  closing LSM significantly reduces the freedom
> of an important class of Linux users, the commercial enterprises, to
> use whatever security framework they desire.  Greg and Alan didn't

No it doesn't. Strange interpretations of peculiar US laws may be doing
that. Thats [with Linux community hat on] _not_our_problem_.

> Why can't a CONFIG_ system be developed that can give everyone pretty
> much what he wants?  It should be possible to develop a system
> permitting much flexibility wrt security frameworks:
>  1.  a kernel configured with statically-linked hooks into exactly
>       one framework.
>                      --- OR ---
>  2.  a kernel configured with an in-tree framework, but which uses
>       an LSM "security_operations" table.  (This is what we pretty much
>       have in 2.6.23).  In addition, a new boot parameter could let the
>       end user name the framework to use, which would completely
>       replace the in-tree default framework at boot time.

Send patches.

> In the same note, he agreed with Alan that "SarBox is not really the issue
> here."  Well, I'm pretty certain that regulatory law strongly shapes
> market forces and enterprise needs.  In particular, I've heard several
> times that enterprises users  really want to just BUY all their security
> products, and that these products must be accompanied by documentation for
> any audits.  So, I'm pretty sure that if it is "not ... the issue", it
> strongly influences the issue.

Corporations practice "liability dumping" so that would be expected. They
want to dumb liability onto their suppliers, their customers and anyone
else they can find. Its the logical commercial practice faced by any
rational body evolving in the US marketplace.

But thats still their issue, no the community's issue. 

Alan

Re: LSM conversion to static interface

[Thomas Fricaccia]

Some well-respected contributors have taken exception my amplification
of Crispin Cowan's point about the patch that closes LSM.

Crispin Cowan <crispin@crispincowan.com> wrote:
>     * It prevents enterprise users, and in fact anyone who isn't
>       comfortable compiling their own kernel, from ever trying out any
>       security module that their distro vendor of choice did not ship.

I extended this point by observing that regulatory laws make it difficult
for enterprise customers to compile their own kernels, mentioning one
of the more invasive statutes, Sarbanes-Oxley.

In reply, "Alan Cox" <alan@lxorguk.ukuu.org.uk> writes:
> Crispin at least is providing genuine discussion points. Sarbox has
> nothing to say on "using vendor linux kernels".

And just previously, "Greg KH" <greg@kroah.com> had written:
> Since when does Sarbanes-Oxley decree that a company must use a
> "standard kernel"?  And just exactly what defines such "standard
> kernel"?  Can you point out where in that bill it requires such a
> thing?

I was actually talking about the *effects* of regulatory law, rather
than the wording in the text of the statutes.  The misunderstanding
could be partially my fault, as my exact words were 

   As Sarbanes-Oxley and other regulatory laws require these
   customers to use "standard kernels" ....

which may not have been as unambiguously clear as I intended.

But as long as we're here, let me elaborate on the point I tried to make.

SOX and other laws require enterprise customers to keep specified
controls on their internal processing procedures, and keep documentation
that can be audited to prove compliance.  The auditing requirements
are extensive and detailed, and certainly include the kernel of an
operating system used to process business and/or financial transactions.

It is within this framework that enterprise customers conclude something
like (and this is vernacular, not the language within the statutes) "if
we use any kernel other than that supplied by our distributor, the
SOX auditing paperwork will be a nightmare."  (I've actually heard
statements similar to this, and so believe that it is an accurate
portrayal of the perception of the effects of regulatory law.  I'm not
a lawyer.)

As I said at the beginning, I meant to amplify Crispin's observation
that enterprise customers are reluctant to compile their own kernels
with the additional observation that the complexities of regulatory
law create obstacles that are significant contributors to that reluctance.

I'll not belabor the unfortunate non sequitur further.  You can find
plenty of documentation of auditing requirements with by Googling
combinations of "Sarbanes-Oxley," "operating system integrity", etc.
This is a big-business topic of wide concern.

 =========

So where were we before that detour?  Oh yes, 

The point of contention:  closing LSM significantly reduces the freedom
of an important class of Linux users, the commercial enterprises, to
use whatever security framework they desire.  Greg and Alan didn't
address this, and neither has anyone else.  Crispin's concluding remark
on the patch closing LSM to modules has also not been addressed:

> So I don't think I am being self-serving in arguing against this
> patch. I just think it is bad for Linux.

Yes.  Why indeed should Linux, justly famous for being configurable
to many disparate purposes, close down an important subsystem so that
only a few types of security frameworks are possible?

Why can't a CONFIG_ system be developed that can give everyone pretty
much what he wants?  It should be possible to develop a system
permitting much flexibility wrt security frameworks:
 1.  a kernel configured with statically-linked hooks into exactly
      one framework.
                     --- OR ---
 2.  a kernel configured with an in-tree framework, but which uses
      an LSM "security_operations" table.  (This is what we pretty much
      have in 2.6.23).  In addition, a new boot parameter could let the
      end user name the framework to use, which would completely
      replace the in-tree default framework at boot time.


To possibly save bandwidth, I'll also respond to another of Greg's points:

"Greg KH" <greg@kroah.com> wrote:
> Any "customer" using a security model other than provided by their Linux
> distributor instantly voided all support from that distro by doing that.

This isn't necessarily true.  In fact, I don't think it's even _remotely_
likely to be typical.

Security is big business, as is compliance with regulatory law.  Large
enterprise customers are NOT going to either void their system support
contracts, or place themselves in jeopardy of failing a SOX audit.
Much more likely would be negotiated collaboration between some Linux
distributors and security software firms that will permit enterprise
customers to purchase, in a bundle, the security software products
they require, along with the documentation needed to prove compliance
with regulatory law.

At least, this seems to be what the market demands, or is beginning to
demand.  Will there be a supply?  Probably, as there is money ready to buy
it.  Can closure of the LSM stop it?  Probably not, but I think that closing
LSM to out-of-tree security modules substantially reduces the viability
of Linux technology, as it fails to address the the needs of an important
class of Linux user, the commercial enterprises.  As I said previously,
I think it will irritate them quite a lot.

Is this really a good idea?  Why is it a good idea to strip important
freedoms from _any_ end user?  Much less a whole class of commercially
important end users?

Furthermore, I don't think it's **necessary** to do an absolute closure in
order to meet the stringent needs of those who demand a single, hard-wired
security framework, such as has been proposed by James Morris.  The KBuild
system seems aptly suited to address the different needs of different users.

 ==========

This just in.  On the issue of making LSM much less available (please
forgive me if I've inaccurately summarized), Crispin just now wrote:

> That is not a catastrophe, it is just tedious. It does not kill baby
> seals, and it does not make Linux utterly useless. OTOH, I think it is
> strictly negative: it takes away user choice in 2 dimensions, and adds
> zero value. So apply it if you must to bake the kernel developer's lives
> easier, but it really is a net loss in Linux kernel capability.

I think that's a pretty good formulation of my points:  user choice is
taken away, leaving a net loss in the capability of Linux, and that
it's not at all necessary.

In the same note, he agreed with Alan that "SarBox is not really the issue
here."  Well, I'm pretty certain that regulatory law strongly shapes
market forces and enterprise needs.  In particular, I've heard several
times that enterprises users  really want to just BUY all their security
products, and that these products must be accompanied by documentation for
any audits.  So, I'm pretty sure that if it is "not ... the issue", it
strongly influences the issue.

Thanks for your consideration,

Tommy F.

Re: LSM conversion to static interface

[Adrian Bunk]

On Sun, Oct 21, 2007 at 08:57:06AM +1000, James Morris wrote:
> On Sat, 20 Oct 2007, Jan Engelhardt wrote:
> 
> > >I'd like to note that I asked people who were actually affected, and had 
> > >examples of their real-world use to step forward and explain their use, 
> > >and that I explicitly mentioned that this is something we can easily 
> > >re-visit.
> > 
> > I do have a pseudo LSM called "multiadm" at 
> > http://freshmeat.net/p/multiadm/ , quoting:
> 
> Based on Linus' criteria, this appears to be a case for reverting the 
> static LSM patch.
>...

If you take it that strictly, the in-kernel root_plug LSM could have 
been considered enough reason for reverting...

The interesting question is IMHO still:

Were Greg and Jan the only people to write such LSMs, or how many 
non-abusive users that make sense as modules do really exist after
5 years?

Either you can count such real-world users with your fingers or there's 
a reason why these modules didn't get included.

IOW:
Either the API has proven to not attract enough modular users or we are 
having a to-be-fixed problem with getting the LSMs submitted and 
included.

> - James

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

Re: LSM conversion to static interface

[James Morris]

On Sat, 20 Oct 2007, Jan Engelhardt wrote:

> >I'd like to note that I asked people who were actually affected, and had 
> >examples of their real-world use to step forward and explain their use, 
> >and that I explicitly mentioned that this is something we can easily 
> >re-visit.
> >
> 
> I do have a pseudo LSM called "multiadm" at 
> http://freshmeat.net/p/multiadm/ , quoting:
> 

Based on Linus' criteria, this appears to be a case for reverting the 
static LSM patch.

Jan, I remember you posting this last year and IIRC, there were really 
only coding style issues to be addressed.  There were some review queries 
and suggestions (e.g. decomposing CAP_SYS_ADMIN), but no deal-breakers -- 
certainly not now that security architecture and security model objections 
are out of bounds.

So, I would suggest reposting the code for upstream inclusion, which 
would be better at least in terms of upstream maintenance, as your code 
will be visible in the tree.


- James
-- 
James Morris
<jmorris@namei.org>

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 19 2007 13:40, Linus Torvalds wrote:
>On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:
>> 
>> Non-trivial modules (i.e., practically everything beyond capabilities) become 
>> effective only after loading policy, anyway. If you can load policy, you can 
>> as well first load a security module without making the system insecure.
>
>I'd like to note that I asked people who were actually affected, and had 
>examples of their real-world use to step forward and explain their use, 
>and that I explicitly mentioned that this is something we can easily 
>re-visit.
>

I do have a pseudo LSM called "multiadm" at 
http://freshmeat.net/p/multiadm/ , quoting:

	The MultiAdmin security framework kernel module provides a means 
	to have multiple "root" users with unique UIDs. This bypasses 
	collation order problems with NSCD, allows you to have files 
	with unique owners, and allows you to track the quota usage for 
	every "real" user. It also implements a "sub-admin", a partially 
	restricted root user who has full read-only access to most 
	subsystems, but write rights only to a limited subset, for 
	example writing to files or killing processes only of certain 
	users.

The use case is so that profs (taking the role of sub-admins), can 
operate on student's data/processes/etc. (quite often needed), but 
without having the full root privileges.

Policy is dead simple since it is based on UIDs. The UID ranges can be 
set on module load time or during runtime (sysfs params). This LSM is 
basically grants extra rights unlike most other LSMs[1], which is why 
modprobe makes much more sense here. (It also does not have to do any 
security labelling that would require it to be loaded at boot time 
already.)

Does that sound productive?


>The fact is, security people *are* insane. You just argue all the time, 
>instead fo doing anything productive. So please don't include me in the Cc 
>on your insane arguments - instead do something productive and I'm 
>interested.

[1] SELinux: What I remember from coker.com.au's selinux test machine, 
everyone had UID 0 and instead had powers revoked.

Re: LSM conversion to static interface

[James Morris]

On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:

> Quoting from commit 20510f2f (Convert LSM into a static interface):
> > In a nutshell, there is no safe way to unload an LSM.  The modular interface
> > is thus unecessary and broken infrastructure.  It is used only by
> > out-of-tree modules, which are often binary-only, illegal, abusive of the
> > API and dangerous, e.g.  silently re-vectoring SELinux.
> 
> This is idiotic. Just because there is no safe way to unload SELinux
> 
>  - doesn't mean there is no safe way to unload other LSMs: if nothing
>    but that, unloading is handy during development.

Can you provide an example of a real LSM which can be safely unloaded and 
also needs to be unloaded?

Why should we maintain infrastructure and extra complexity in the kernel 
for theoretical or unknown modules ?

Linus has asked for any valid out of tree users who need a dynamic 
interface to step forward.  Where are they?

As one of the people who actually maintains LSM (rather than simply 
speculates about it), I object to maintaining infrastructure which, to the 
best of my knowledge, is only used by out of tree, binary, broken junk.

If you recall, the original motivation for this patch was when the idea 
of adding a new capability to control security model unload was raised.  

That is, new security infrastructure was being proposed merely to cater to 
some other existing unnecessary security infrastructure.  So, rather than 
doing that, I proposed removing the unnecessary infrastructure.

I agree with Linus: if you can demonstrate a valid, concrete use for 
dynamic LSMs, then the infrastructure to support them can easily be 
reinstated.

But until then, it seems both reasonable and in keeping with good kernel 
development practices, to not maintain unused infrastructure.


- James
-- 
James Morris
<jmorris@namei.org>

Re: LSM conversion to static interface

[Linus Torvalds]

On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:
> 
> Non-trivial modules (i.e., practically everything beyond capabilities) become 
> effective only after loading policy, anyway. If you can load policy, you can 
> as well first load a security module without making the system insecure.

I'd like to note that I asked people who were actually affected, and had 
examples of their real-world use to step forward and explain their use, 
and that I explicitly mentioned that this is something we can easily 
re-visit.

But I also note that you did no such thing, neither has anybody else.

The fact is, security people *are* insane. You just argue all the time, 
instead fo doing anything productive. So please don't include me in the Cc 
on your insane arguments - instead do something productive and I'm 
interested.

Ok? That was the whole point of LSM in the first place. I'm *not* 
interested in getting roped into your insane arguments. I'm interested in 
moving forward and having real examples of real use and code. Until then, 
this issue is closed. I thought I had made that clear already, but 
apparently not clear enough.

So I repeat: we can undo that commit, but I will damn well not care one 
whit about yet another pointless security model flamewar.

		Linus

Re: LSM conversion to static interface

[Andreas Gruenbacher]

On Thursday 18 October 2007 04:18, Linus Torvalds wrote:
> On Wed, 17 Oct 2007, Thomas Fricaccia wrote:
> > 
> > But then I noticed that, while the LSM would remain in existence, it was 
> > being closed to out-of-tree security frameworks.  Yikes!  Since then, 
> > I've been following the rush to put SMACK, TOMOYO and AppArmor 
> > "in-tree".
> 
> Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE 
> people were ok with it (AppArmor), but I'm with you - I applied it, but 
> I'm also perfectly willing to unapply it if there actually are valid 
> out-of-tree users that people push for not merging.

The patch doesn't hurt AppArmor, but it's still a step in the wrong direction.

Quoting from commit 20510f2f (Convert LSM into a static interface):
> In a nutshell, there is no safe way to unload an LSM.  The modular interface
> is thus unecessary and broken infrastructure.  It is used only by
> out-of-tree modules, which are often binary-only, illegal, abusive of the
> API and dangerous, e.g.  silently re-vectoring SELinux.

This is idiotic. Just because there is no safe way to unload SELinux

 - doesn't mean there is no safe way to unload other LSMs: if nothing
   but that, unloading is handy during development.

 - doesn't mean that module *loading* is unsafe. The patch removes module
   loading as well, which hurts more than removing module unloading.

LSM can be abused ... so what, this doesn't mean the interface is bad. Non-LSM 
loadable modules have been known to do lots of bad things, and yet nobody 
made them non-loadable either (yet).

> [...]
> For example, I do kind of see the point that a "real" security model might 
> want to be compiled-in, and not something you override from a module.

Non-trivial modules (i.e., practically everything beyond capabilities) become 
effective only after loading policy, anyway. If you can load policy, you can 
as well first load a security module without making the system insecure.

Thanks,
Andreas

Re: LSM conversion to static interface

[Arjan van de Ven]

On Wed, 17 Oct 2007 18:34:16 -0700
"Thomas Fricaccia" <thomas_fricacci@yahoo.com> wrote:
> 
> But then I noticed that, while the LSM would remain in existence, it
> was being closed to out-of-tree security frameworks.  Yikes!  Since
> then, I've been following the rush to put SMACK, TOMOYO and AppArmor
> "in-tree". 

I think your statement isn't quite correct: it's not closed to out of
tree security frameworks; it's no longer possible to do MODULES. You
can easily patch any of the ones you mention in (and in fact, this is
how distros that use apparmor will use it anyway). You are totally free
to compile whatever security module you want into your kernel and use
it... I would actually highly encourage that; the freedom to do that is
what Linux is about.

The problem with "loadable security modules" is actually fundamental,
and afaik even the AppArmor people mostly agree with this: The security
any such system provides is generally based on being in a "Safe" state
from the start, so knowing all objects that go through the system, being
able to label them (or at least do something with them, I realize the
term "label" is maybe seen as SELinux specific, but I mean it in a
generic way; the SELinux people will tell you I'm not a fan of their
approach *at all*), check them etc etc. A loadable-module approach can't
do that, it would, at load time, have to inspect the system, make sure
no operations are in "half process" when the LSM hooks go into effect
(just think of it: if you have an operation that gets 3 LSM checks done
to it, and you load and activate your module after the first one is
done as NOP, and your code only sees the 2nd and 3rd... showing that
that gives you sane behavior.... unpleasant no matter what you do) and
on unload, undo all it's work in a semi atomic way (just try doing it
race free is already impossible).

This is the prime motivation behind the change as I understand it: It
wasn't really an option to get this correct, the distros who deploy
these frameworks tend to compile them in anyway as a result, and there
are real downsides as well (see below).

> technical arguments seem to be (1) some people use the LSM interface
> for "non-security" purposes, which is frowned upon, (2) it's
> difficult to properly secure a system with an open-ended interface
> like LSM, and (3) my security framework should be all any fair-minded
> person would ever want, so we won't let you use something else.


you missed another one: the curent (now merged) patch allows a new
option (which is under development and will be proposed for 2.6.25): A
config option to compile the kernel such that the security framework of
your choice gets compiled as "exclusive" for your binary kernel, and
such that the code doesn't go via the LSM function pointers anymore, but
just via preprocessor rules, does direct calls instead. (And gets
patched out if you issue kernel commandline options to disable security
entirely). This takes away one of the main performance overheads of LSM
(many many function pointer calls) for those who know which LSM module
they'll be using.

That option obviously doesn't mean that you can't have multiple LSM
drivers anymore in the kernel, again it is an option that IF you know
you'll only use one, you can get rid of all the overhead of needing to
be ready to do multiple.

While this strict technically isn't in conflict with the non-modular
LSM (modular-LSM can obviously be a config option in itself as well),
it does make it a lot easier and cleaner to do things this way.

Re: LSM conversion to static interface

[Linus Torvalds]

On Wed, 17 Oct 2007, Casey Schaufler wrote:
> 
> The in-tree vs out-of-tree discussion is independent of LSM.

Indeed. I think there is certainly likely to be some small overlap, but I 
*think* they are largely independent issues - "do we want choice in 
securitu models" (a very emphatic YES as far as I'm concerned) vs "do we 
necessarily want to do them as out-of-tree modules" (I'd like people who 
actually *do* things like that to educate us on why and what they are 
doing).

Hmm?

		Linus

Re: LSM conversion to static interface

[Linus Torvalds]

On Wed, 17 Oct 2007, Thomas Fricaccia wrote:
> 
> But then I noticed that, while the LSM would remain in existence, it was 
> being closed to out-of-tree security frameworks.  Yikes!  Since then, 
> I've been following the rush to put SMACK, TOMOYO and AppArmor 
> "in-tree".

Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE 
people were ok with it (AppArmor), but I'm with you - I applied it, but 
I'm also perfectly willing to unapply it if there actually are valid 
out-of-tree users that people push for not merging.

So Í don't think this is settled in any way - please keep discussing, and 
bringing it up. I'm definitely not in the camp that thinks that LSM needs 
to be "controlled", but on the other hand, I'm also not going to undo that 
commit unless there are good real arguments for undoing it (not just 
theoretical ones).

For example, I do kind of see the point that a "real" security model might 
want to be compiled-in, and not something you override from a module. Of 
course, I'm personally trying to not use any modules at all, so I'm just 
odd and contrary, so whatever..

Real usage scenarios with LSM modules, please speak up!

		Linus

Re: LSM conversion to static interface

[Casey Schaufler]

--- Thomas Fricaccia <thomas_fricacci@yahoo.com> wrote:

> ...
> 
> But then I noticed that, while the LSM would remain in existence, it was
> being closed to out-of-tree security frameworks.  Yikes!  Since then, I've
> been following the rush to put SMACK, TOMOYO and AppArmor "in-tree". 
> 
> Since I know that the people behind these security frameworks are serious and
> worthy folk of general good repute,

I make no claims to worthyness, strongly deny being serious,
and challenge you to demonstrate my good repute.

> I've reluctantly come to the tentative
> conclusion that the fix is in. 

Nope. I remain carefully neutral regarding the static/dynamic LSM
issue. I was involved with the LSM when SELinux was still known as
the Flask port and my development group proposed the first
implementation, featuring authoritative hooks. Believe me, this
is nothing compared to what we went through as a community then.

> There seem to be powers at work that want LSM
> closed, and they don't want much public discussion about it.

The thing that killed authoritative hooks and that could kill LSM
is the notion (which I refuse to take a side on) that out of tree
facilities can use it to avoid the stated intent of the GPL.

> I think this is bad technology.  I've done due diligence by reviewing the
> LKML discussion behind closing LSM (and there isn't much).

I think the primary parties have gotten to the point where they
just call out the arguments by number we've been over them so many
times.

> The technical
> arguments seem to be (1) some people use the LSM interface for "non-security"
> purposes, which is frowned upon,

It goes way beyond frowned upon. The first use proposed for LSM was
an audit implementation and that was throughly shredded. Additional
restrictions on accesses only.

> (2) it's difficult to properly secure a
> system with an open-ended interface like LSM, and 

Which is pure feldercarb.

> (3) my security framework
> should be all any fair-minded person would ever want, so we won't let you use
> something else.

That argument makes Linus mad.

> Exactly. 
> 
> Well, any system that permits loading code into "ring 0" can't be made
> completely secure, so argument 2 reduces to argument 3, which is
> transparently self-serving (and invalid).
> 
> I submit for discussion the idea that a free and open operating system should
> preserve as much freedom for the end user as possible.  To this end, the
> kernel should cleanly permit and support the deployment of ANY security
> framework the end user desires, whether "in-tree" or "out-of-tree".  I agree
> that any out-of-tree LSM module should be licensed under the GPL (if for no
> other reason than many current commercial support contracts require
> non-tainted kernels).
> 
> But restricting security frameworks to "in-tree" only is bad technology.
> 
> "Freedom" includes the power to do bad things to yourself by, for example,
> making poor choices in security frameworks.  This possible and permitted end
> result shouldn't be the concern of kernel developers.  Making configuration
> and installation of user-chosen frameworks as clean and safe as possible
> should be.
> 
> In my opinion.
> 
> Though not sure why, I expect to be scorched by this.  Try not to patronize
> or condescend.  Give me technical arguments backed by real data.  Show me why
> a home user or 10,000 node commercial enterprise shouldn't be able to choose
> what he wants for security without having to jump through your hoops.  Show
> me why you shouldn't make his use of technology up to him, and as safely and
> conveniently as you can contrive.

The in-tree vs out-of-tree discussion is independent of LSM.


Casey Schaufler
casey@schaufler-ca.com

LSM conversion to static interface

[Thomas Fricaccia]

Like many of us who earn a good living with Linux (for over a decade now) and follow the kernel developer discussions with waxing and waning interest depending on topic, I noticed James Morris' proposal to eliminate the LSM in favor of ordaining SELinux as THE security framework forever and amen, followed by the definitive decision by Linus that LSM would remain.

Well, good, I thought.  Linux should continue to represent freedom for anyone to use basic technology in any way he sees fit.  I turned my attention back to my prosaic day-to-day concerns, thinking that the choice of which security framework to deploy would remain in the hands of the user, regardless of which distributor he chose.

But then I noticed that, while the LSM would remain in existence, it was being closed to out-of-tree security frameworks.  Yikes!  Since then, I've been following the rush to put SMACK, TOMOYO and AppArmor "in-tree". 

Since I know that the people behind these security frameworks are serious and worthy folk of general good repute, I've reluctantly come to the tentative conclusion that the fix is in.  There seem to be powers at work that want LSM closed, and they don't want much public discussion about it.

I think this is bad technology.  I've done due diligence by reviewing the LKML discussion behind closing LSM (and there isn't much).  The technical arguments seem to be (1) some people use the LSM interface for "non-security" purposes, which is frowned upon, (2) it's difficult to properly secure a system with an open-ended interface like LSM, and (3) my security framework should be all any fair-minded person would ever want, so we won't let you use something else.

Exactly. 

Well, any system that permits loading code into "ring 0" can't be made completely secure, so argument 2 reduces to argument 3, which is transparently self-serving (and invalid).

I submit for discussion the idea that a free and open operating system should preserve as much freedom for the end user as possible.  To this end, the kernel should cleanly permit and support the deployment of ANY security framework the end user desires, whether "in-tree" or "out-of-tree".  I agree that any out-of-tree LSM module should be licensed under the GPL (if for no other reason than many current commercial support contracts require non-tainted kernels).

But restricting security frameworks to "in-tree" only is bad technology.

"Freedom" includes the power to do bad things to yourself by, for example, making poor choices in security frameworks.  This possible and permitted end result shouldn't be the concern of kernel developers.  Making configuration and installation of user-chosen frameworks as clean and safe as possible should be.

In my opinion.

Though not sure why, I expect to be scorched by this.  Try not to patronize or condescend.  Give me technical arguments backed by real data.  Show me why a home user or 10,000 node commercial enterprise shouldn't be able to choose what he wants for security without having to jump through your hoops.  Show me why you shouldn't make his use of technology up to him, and as safely and conveniently as you can contrive.

Thanks for a really great operating system, I really love it,

 Tommy F.