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.
--- Thomas Fricaccia <[email protected]> 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
[email protected]
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
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
On Wed, 17 Oct 2007 18:34:16 -0700
"Thomas Fricaccia" <[email protected]> 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.
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
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
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
<[email protected]>
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.
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
<[email protected]>
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
To discuss how LSM should work, it would have been really helpful if the
OP had cc'd the LSM mailing list. I've cc'd the LSM list here ...
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.
>
I did not speak up against this patch because it does not hurt AppArmor,
and I was trying to reduce the amount of LKML flaming that I engage in
:) but since you asked, IMHO this patch is extremely bad for Linux and
bad for Linux users.
The patch does have benefits, I just think those benefits are weak and
unimportant. It prohibits dynamic loading of security modules (you must
be compiled in) and prohibits unloading of security modules (because it
is unsafe, and potentially insecure). What makes these benefits weak and
unimportant is that you can have those benefits now without the patch by
just writing your module that way: if you think that a security module
should be compiled in and present when the kernel boots, and should
never be unloaded.
> 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..
>
Why would you want to dynamically unload a module: because it is
convenient for debugging. Ok, so it is unsafe, and sometimes wedges your
kernel, which sometimes forces you to reboot. With this patch in place,
it forces you to *always* reboot when you want to try a hack to the module.
Why you would want to dynamically load a security module: because you
are an enterprise user, required to use a specific build of a kernel,
rather than compile your own kernel, but you also want to use (or even
try out) a security module that your enterprise's vendor of choice has
not chosen to bundle. In the current state, such a user can just go get
a module and use it. With this patch, such a user is just screwed, they
can't load and try the module without having to get into kernel building.
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
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 <[email protected]> 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
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
On Sun, 21 Oct 2007 19:24:42 -0700
"Thomas Fricaccia" <[email protected]> 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".
Alan Cox wrote:
> On Sun, 21 Oct 2007 19:24:42 -0700
> "Thomas Fricaccia" <[email protected]> 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
> > 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
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
Some well-respected contributors have taken exception my amplification
of Crispin Cowan's point about the patch that closes LSM.
Crispin Cowan <[email protected]> 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" <[email protected]> writes:
> Crispin at least is providing genuine discussion points. Sarbox has
> nothing to say on "using vendor linux kernels".
And just previously, "Greg KH" <[email protected]> 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" <[email protected]> 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.
> 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
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" <[email protected]> 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
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
On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
James Morris <[email protected]> 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.
I don't want to argue for or against the actual revert; however if Linus/James/Chris
decide to do a revert, I've made a patch to do that below
(doing a full git revert is tricky since it gets mixed up with various other cleanup
patches; even inside the original patch. I've done the relevant pieces by hand via a
selective patch -R and compile-tested it). In addition I've made the modularity a
Kconfig option, since it's clearly something that is contested and thus is justified
as a user compile time choice; people who don't want this (out of paranoia or otherwise)
can now decide to disable, while others who want to experiment or use out of tree
LSM modules, can select the KConfig option.
If it turns out that the above module becomes unmaintained and no longer usable, and no
other useful cases show up, we can always garbage collect this code in the future; it's
now low-overhead anyway for those who care, due to the KConfig option.
---
From: Arjan van de Ven <[email protected]>
Subject: revert the modular LSM patch
Since there is a real out of tree, non-racey modular LSM module,
add back the capability to have modular LSM modules as a config option.
(note that this patch fails checkpatch.pl in a few places, however
since this is just a reverse-patch of the original code, I don't
want to fix this in order to keep exact revert behavior)
Signed-off-by: Arjan van de Ven <[email protected]>
diff -purN linux-2.6.23-git17/include/linux.org/security.h linux-2.6.23-git17/include/linux/security.h
--- linux-2.6.23-git17/include/linux.org/security.h 2007-10-21 10:35:49.000000000 +0200
+++ linux-2.6.23-git17/include/linux/security.h 2007-10-21 10:36:00.000000000 +0200
@@ -1178,6 +1178,10 @@ struct request_sock;
* allow module stacking.
* @name contains the name of the security module being stacked.
* @ops contains a pointer to the struct security_operations of the module to stack.
+ * @unregister_security:
+ * remove a stacked module.
+ * @name contains the name of the security module being unstacked.
+ * @ops contains a pointer to the struct security_operations of the module to unstack.
*
* @secid_to_secctx:
* Convert secid to security context.
@@ -1365,6 +1369,8 @@ struct security_operations {
/* allow module stacking */
int (*register_security) (const char *name,
struct security_operations *ops);
+ int (*unregister_security) (const char *name,
+ struct security_operations *ops);
void (*d_instantiate) (struct dentry *dentry, struct inode *inode);
@@ -1445,7 +1451,9 @@ struct security_operations {
/* prototypes */
extern int security_init (void);
extern int register_security (struct security_operations *ops);
+extern int unregister_security (struct security_operations *ops);
extern int mod_reg_security (const char *name, struct security_operations *ops);
+extern int mod_unreg_security (const char *name, struct security_operations *ops);
extern struct dentry *securityfs_create_file(const char *name, mode_t mode,
struct dentry *parent, void *data,
const struct file_operations *fops);
diff -purN linux-2.6.23-git17/security.org/dummy.c linux-2.6.23-git17/security/dummy.c
--- linux-2.6.23-git17/security.org/dummy.c 2007-10-21 02:04:21.000000000 +0200
+++ linux-2.6.23-git17/security/dummy.c 2007-10-21 10:36:00.000000000 +0200
@@ -908,6 +908,11 @@ static int dummy_register_security (cons
return -EINVAL;
}
+static int dummy_unregister_security (const char *name, struct security_operations *ops)
+{
+ return -EINVAL;
+}
+
static void dummy_d_instantiate (struct dentry *dentry, struct inode *inode)
{
return;
@@ -1082,6 +1087,7 @@ void security_fixup_ops (struct security
set_to_dummy_if_null(ops, netlink_send);
set_to_dummy_if_null(ops, netlink_recv);
set_to_dummy_if_null(ops, register_security);
+ set_to_dummy_if_null(ops, unregister_security);
set_to_dummy_if_null(ops, d_instantiate);
set_to_dummy_if_null(ops, getprocattr);
set_to_dummy_if_null(ops, setprocattr);
diff -purN linux-2.6.23-git17/security.org/Kconfig linux-2.6.23-git17/security/Kconfig
--- linux-2.6.23-git17/security.org/Kconfig 2007-10-21 02:04:21.000000000 +0200
+++ linux-2.6.23-git17/security/Kconfig 2007-10-21 10:36:14.000000000 +0200
@@ -51,6 +51,20 @@ config SECURITY
If you are unsure how to answer this question, answer N.
+config SECURITY_MODULAR
+ bool "Allow loadable security models"
+ depends on SECURITY
+ help
+ This allows you to load and unload security modules at
+ runtime.
+
+ This option is useful for developers of security modules
+ or for experimenting with security modules that are not in
+ your kernel (yet). Note that (un)loading security modules
+ can be a dangerous situation so use with care.
+
+ If you are unsure how to answer this question, answer N.
+
config SECURITY_NETWORK
bool "Socket and Networking Security Hooks"
depends on SECURITY
diff -purN linux-2.6.23-git17/security.org/security.c linux-2.6.23-git17/security/security.c
--- linux-2.6.23-git17/security.org/security.c 2007-10-21 02:04:21.000000000 +0200
+++ linux-2.6.23-git17/security/security.c 2007-10-21 10:37:41.000000000 +0200
@@ -71,7 +71,8 @@ int __init security_init(void)
*
* This function is to allow a security module to register itself with the
* kernel security subsystem. Some rudimentary checking is done on the @ops
- * value passed to this function.
+ * value passed to this function. A call to unregister_security() should be
+ * done to remove this security_options structure from the kernel.
*
* If there is already a security module registered with the kernel,
* an error will be returned. Otherwise 0 is returned on success.
@@ -121,6 +122,62 @@ int mod_reg_security(const char *name, s
return security_ops->register_security(name, ops);
}
+#ifdef CONFIG_SECURITY_MODULAR
+/**
+ * unregister_security - unregisters a security framework with the kernel
+ * @ops: a pointer to the struct security_options that is to be registered
+ *
+ * This function removes a struct security_operations variable that had
+ * previously been registered with a successful call to register_security().
+ *
+ * If @ops does not match the valued previously passed to register_security()
+ * an error is returned. Otherwise the default security options is set to the
+ * the dummy_security_ops structure, and 0 is returned.
+ */
+int unregister_security(struct security_operations *ops)
+{
+ if (ops != security_ops) {
+ printk(KERN_INFO "%s: trying to unregister "
+ "a security_opts structure that is not "
+ "registered, failing.\n", __FUNCTION__);
+ return -EINVAL;
+ }
+
+ security_ops = &dummy_security_ops;
+
+ return 0;
+}
+
+/**
+ * mod_unreg_security - allows a security module registered with mod_reg_security() to be unloaded
+ * @name: a pointer to a string with the name of the security_options to be removed
+ * @ops: a pointer to the struct security_options that is to be removed
+ *
+ * This function allows security modules that have been successfully registered
+ * with a call to mod_reg_security() to be unloaded from the system.
+ * This calls the currently loaded security module's unregister_security() call
+ * with the @name and @ops variables.
+ *
+ * The return value depends on the currently loaded security module, with 0 as
+ * success.
+ */
+int mod_unreg_security(const char *name, struct security_operations *ops)
+{
+ if (ops == security_ops) {
+ printk(KERN_INFO "%s invalid attempt to unregister "
+ " primary security ops.\n", __FUNCTION__);
+ return -EINVAL;
+ }
+
+ return security_ops->unregister_security(name, ops);
+}
+
+EXPORT_SYMBOL_GPL(register_security);
+EXPORT_SYMBOL_GPL(unregister_security);
+EXPORT_SYMBOL_GPL(mod_reg_security);
+EXPORT_SYMBOL_GPL(mod_unreg_security);
+#endif
+
/* Security operations */
int security_ptrace(struct task_struct *parent, struct task_struct *child)
diff -purN linux-2.6.23-git17/security.org/selinux/hooks.c linux-2.6.23-git17/security/selinux/hooks.c
--- linux-2.6.23-git17/security.org/selinux/hooks.c 2007-10-21 02:04:21.000000000 +0200
+++ linux-2.6.23-git17/security/selinux/hooks.c 2007-10-21 10:38:27.000000000 +0200
@@ -4549,6 +4549,19 @@ static int selinux_register_security (co
return 0;
}
+static int selinux_unregister_security (const char *name, struct security_operations *ops)
+{
+ if (ops != secondary_ops) {
+ printk(KERN_ERR "%s: trying to unregister a security module "
+ "that is not registered.\n", __FUNCTION__);
+ return -EINVAL;
+ }
+
+ secondary_ops = original_ops;
+
+ return 0;
+}
+
static void selinux_d_instantiate (struct dentry *dentry, struct inode *inode)
{
if (inode)
@@ -4895,6 +4908,7 @@ static struct security_operations selinu
.sem_semop = selinux_sem_semop,
.register_security = selinux_register_security,
+ .unregister_security = selinux_unregister_security,
.d_instantiate = selinux_d_instantiate,
On Mon, 22 Oct 2007, Arjan van de Ven wrote:
> @@ -4895,6 +4908,7 @@ static struct security_operations selinu
> .sem_semop = selinux_sem_semop,
>
> .register_security = selinux_register_security,
> + .unregister_security = selinux_unregister_security,
>
> .d_instantiate = selinux_d_instantiate,
You also need to consider whether to allow capabilities to be built as an
unloadable module. If not, then we don't need this hook added back into
SELinux. Otherwise, if it is desired, you also need to reinstate
capability_exit and general modular bits for security/capability.c.
- James
--
James Morris
<[email protected]>
On Tue, 23 Oct 2007 14:56:52 +1000 (EST)
James Morris <[email protected]> wrote:
> On Mon, 22 Oct 2007, Arjan van de Ven wrote:
>
> > @@ -4895,6 +4908,7 @@ static struct security_operations selinu
> > .sem_semop = selinux_sem_semop,
> >
> > .register_security =
> > selinux_register_security,
> > + .unregister_security =
> > selinux_unregister_security,
> > .d_instantiate = selinux_d_instantiate,
>
> You also need to consider whether to allow capabilities to be built
> as an unloadable module. If not, then we don't need this hook added
> back into SELinux. Otherwise, if it is desired, you also need to
> reinstate capability_exit and general modular bits for
> security/capability.c.
>
this just allows 3d party replacements of capability like functions;
there is no need/point to have the existing capability back as modular
to be honest.
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
* Arjan van de Ven ([email protected]) wrote:
> On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
> James Morris <[email protected]> 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.
>
> I don't want to argue for or against the actual revert; however if Linus/James/Chris
> decide to do a revert, I've made a patch to do that below
Thanks Arjan. I did not actually oppose making it non-modular, and
thought there was sufficient time for people to complain meaningfully
on that change. I also think there's not a lot of value in the modular
interface, but it's very difficult to have rational discussions in this
area.
> (doing a full git revert is tricky since it gets mixed up with various other cleanup
> patches; even inside the original patch. I've done the relevant pieces by hand via a
> selective patch -R and compile-tested it). In addition I've made the modularity a
> Kconfig option, since it's clearly something that is contested and thus is justified
> as a user compile time choice; people who don't want this (out of paranoia or otherwise)
> can now decide to disable, while others who want to experiment or use out of tree
> LSM modules, can select the KConfig option.
>
> If it turns out that the above module becomes unmaintained and no longer usable, and no
> other useful cases show up, we can always garbage collect this code in the future; it's
> now low-overhead anyway for those who care, due to the KConfig option.
Yes, and I think we can still improve performance although I can't see
anyway to help out the modular case, so I guess it will have to incur
the hit that's always been there. I think your Kconfig option is a
decent compromise.
thanks,
-chris
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
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
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 <[email protected]> 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" <[email protected]> writes:
>> Crispin at least is providing genuine discussion points. Sarbox has
>> nothing to say on "using vendor linux kernels".
>
> And just previously, "Greg KH" <[email protected]> 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
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
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
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.
On Oct 22 2007 22:16, Chris Wright wrote:
>>
>> If it turns out that the above module becomes unmaintained and no
>> longer usable, and no other useful cases show up, we can always
>> garbage collect this code in the future; it's now low-overhead
>> anyway for those who care, due to the KConfig option.
>
>Yes, and I think we can still improve performance although I can't see
>anyway to help out the modular case, so I guess it will have to incur
>the hit that's always been there. I think your Kconfig option is a
>decent compromise.
(Un)registering security modules is a one-time hit. You do not load
and unload modules on a per-minute basis outside debugging.
* Jan Engelhardt ([email protected]) wrote:
> On Oct 22 2007 22:16, Chris Wright wrote:
> >Yes, and I think we can still improve performance although I can't see
> >anyway to help out the modular case, so I guess it will have to incur
> >the hit that's always been there. I think your Kconfig option is a
> >decent compromise.
>
> (Un)registering security modules is a one-time hit. You do not load
> and unload modules on a per-minute basis outside debugging.
I'm referring to the hit for indirect calls
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?
On Oct 23 2007 02:13, Chris Wright wrote:
>* Jan Engelhardt ([email protected]) wrote:
>> On Oct 22 2007 22:16, Chris Wright wrote:
>> >Yes, and I think we can still improve performance although I can't see
>> >anyway to help out the modular case, so I guess it will have to incur
>> >the hit that's always been there. I think your Kconfig option is a
>> >decent compromise.
>>
>> (Un)registering security modules is a one-time hit. You do not load
>> and unload modules on a per-minute basis outside debugging.
>
>I'm referring to the hit for indirect calls
Indeed, I just seen that. Not too nice :(
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
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?
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
Quoting Jan Engelhardt ([email protected]):
>
> 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
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.
Quoting Jan Engelhardt ([email protected]):
>
> 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
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
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 -- [email protected]
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
Chris Wright wrote:
> Yes, and I think we can still improve performance although I can't see
> anyway to help out the modular case, so I guess it will have to incur
> the hit that's always been there.
Broaden the paravirt patching machinery?
J
* Jeremy Fitzhardinge ([email protected]) wrote:
> Chris Wright wrote:
> > Yes, and I think we can still improve performance although I can't see
> > anyway to help out the modular case, so I guess it will have to incur
> > the hit that's always been there.
>
> Broaden the paravirt patching machinery?
Yup, that's essentially what we've been talking about.
thanks,
-chris
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!
http://www.kroah.com/lkn/
thanks,
greg k-h
On Tue, 23 Oct 2007 17:31:28 -0700
Jeremy Fitzhardinge <[email protected]> wrote:
> Chris Wright wrote:
> > Yes, and I think we can still improve performance although I can't
> > see anyway to help out the modular case, so I guess it will have to
> > incur the hit that's always been there.
>
> Broaden the paravirt patching machinery?
>
so far I've something much simpler in mind, I have a first prototype
and it shows code that is pretty much optimal on modern cpus.
I hope to have something postable in a week or so
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
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
On 24/10/07 13:55, Adrian Bunk 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?
No, because the interface for configuring it would be rejected... I have
a /proc file which I write a binary configuration file to. This works
fine for me but it would take a lot of work to write a proper interface
- which I'm still not sure how to do*.
That doesn't solve the problem that it's no longer possible to reload LSM
modules to make changes at runtime. Why should I have to reboot to change
something from now on when it works ok? The reasoning seems to be based
around a dislike of some out of tree modules. (Although it doesn't look
like there's appropriate locking around the register/unregister process.)
* (I've got a list of access rules which are scanned in order until one of
them matches, and an array of one bit for every port for per-port default
allow/deny - although the latter could be removed.
http://svn.lp0.eu/simon/portac/trunk/)
--
Simon Arlott
On Oct 24 2007 19:11, Simon Arlott wrote:
>
>* (I've got a list of access rules which are scanned in order until one of
>them matches, and an array of one bit for every port for per-port default
>allow/deny - although the latter could be removed.
>http://svn.lp0.eu/simon/portac/trunk/)
Besides the 'feature' of inhibiting port binding,
is not this task of blocking connections something for a firewall?
On 24/10/07 19:51, Jan Engelhardt wrote:
> On Oct 24 2007 19:11, Simon Arlott wrote:
>>
>>* (I've got a list of access rules which are scanned in order until one of
>>them matches, and an array of one bit for every port for per-port default
>>allow/deny - although the latter could be removed.
>>http://svn.lp0.eu/simon/portac/trunk/)
>
> Besides the 'feature' of inhibiting port binding,
> is not this task of blocking connections something for a firewall?
The firewall blocks incoming connections where appropriate, yes, but it
doesn't stop one user binding to a port that another user expected to be able
to use. "Ownership" of ports (1-1023) shouldn't be something only root (via
CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports
below 1024 and it's useful to be able to prevent users from binding to them
too.
--
Simon Arlott
On Oct 24 2007 19:59, Simon Arlott wrote:
>On 24/10/07 19:51, Jan Engelhardt wrote:
>> On Oct 24 2007 19:11, Simon Arlott wrote:
>>>
>>>* (I've got a list of access rules which are scanned in order until one of
>>>them matches, and an array of one bit for every port for per-port default
>>>allow/deny - although the latter could be removed.
>>>http://svn.lp0.eu/simon/portac/trunk/)
>>
>> Besides the 'feature' of inhibiting port binding,
>> is not this task of blocking connections something for a firewall?
>
>The firewall blocks incoming connections where appropriate, yes, but it
>doesn't stop one user binding to a port that another user expected to be able
>to use. "Ownership" of ports (1-1023) shouldn't be something only root (via
>CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports
>below 1024 and it's useful to be able to prevent users from binding to them
>too.
Indeed.
There has been a feature in the security framework that probably did
not get much attention. It looks like YAGNI first, but on a closer look,
it becomes useful pretty quick - secondary_register.
As more and more simple LSM plugins pop up, stacking/chaining by means
of secondary_register becomes attractive again, especially if these LSMs
target different actions. This is probably the most useful thing why
the LSM interface should remain modular:
# Secure my files
modprobe apparmor
# -*- assuming apparmor implemented secondaries -*-
# Secure my ports
modprobe portac
# More rights to users
modprobe multiadm
# -*- whatever else comes along -*-
Jan Engelhardt wrote:
> On Oct 24 2007 19:11, Simon Arlott wrote:
>
>> * (I've got a list of access rules which are scanned in order until one of
>> them matches, and an array of one bit for every port for per-port default
>> allow/deny - although the latter could be removed.
>> http://svn.lp0.eu/simon/portac/trunk/)
>>
> Besides the 'feature' of inhibiting port binding,
> is not this task of blocking connections something for a firewall?
>
So now you are criticizing his module. Arguing about the merits of
security semantics. This is exactly why Linus wanted LSM, so we don't
have to have these kinds of discussions, at least not on LKML :)
It seems to me that LSM used to be an open API. Anyone could code to it,
so you could at least try to ship a module that will load into a major
vendor's stock kernel for an important release.
Now with this change, it is effectively a closed API. You can only load
the modules that the distro vendor shipped to you. If you want
*anything* other than what RH or Novell or Canonical or Mandriva etc.
says you should want, then you have to hack the source code for your kernel.
Open source is great, and it is wonderful that you *can* hack the source
if you need to, but demanding that end users patch their source code
when all they want to do is load a module is really, really sad.
Please revert this patch. Its benefits are no where near its costs.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Itanium. Vista. GPLv3. Complexity at work
On Oct 24 2007 13:18, Crispin Cowan wrote:
>Jan Engelhardt wrote:
>> On Oct 24 2007 19:11, Simon Arlott wrote:
>>
>>> * (I've got a list of access rules which are scanned in order until one of
>>> them matches, and an array of one bit for every port for per-port default
>>> allow/deny - although the latter could be removed.
>>> http://svn.lp0.eu/simon/portac/trunk/)
>>>
>> Besides the 'feature' of inhibiting port binding,
>> is not this task of blocking connections something for a firewall?
>>
>So now you are criticizing his module. Arguing about the merits of
>security semantics. This is exactly why Linus wanted LSM, so we don't
>have to have these kinds of discussions, at least not on LKML :)
This was a question. I was perfectly aware that iptables alone
does not prohibit binding, and there are reasons to inhibit binding.
But sometimes, a coder does not know where to start - chances are,
that someone else wanting to do bind(2) inhibiting is doing it
with a syscall table change. Or coder did not notice that a firewall
is sufficient for the task to be achieved (which is not always the
case - hence the question).
On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> On Oct 24 2007 19:59, Simon Arlott wrote:
> >On 24/10/07 19:51, Jan Engelhardt wrote:
> >> On Oct 24 2007 19:11, Simon Arlott wrote:
> >>>
> >>>* (I've got a list of access rules which are scanned in order until one of
> >>>them matches, and an array of one bit for every port for per-port default
> >>>allow/deny - although the latter could be removed.
> >>>http://svn.lp0.eu/simon/portac/trunk/)
> >>
> >> Besides the 'feature' of inhibiting port binding,
> >> is not this task of blocking connections something for a firewall?
> >
> >The firewall blocks incoming connections where appropriate, yes, but it
> >doesn't stop one user binding to a port that another user expected to be able
> >to use. "Ownership" of ports (1-1023) shouldn't be something only root (via
> >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports
> >below 1024 and it's useful to be able to prevent users from binding to them
> >too.
>
> Indeed.
>
>
> There has been a feature in the security framework that probably did
> not get much attention. It looks like YAGNI first, but on a closer look,
> it becomes useful pretty quick - secondary_register.
>
> As more and more simple LSM plugins pop up, stacking/chaining by means
> of secondary_register becomes attractive again, especially if these LSMs
> target different actions. This is probably the most useful thing why
> the LSM interface should remain modular:
>
> # Secure my files
> modprobe apparmor
> # -*- assuming apparmor implemented secondaries -*-
> # Secure my ports
> modprobe portac
> # More rights to users
> modprobe multiadm
> # -*- whatever else comes along -*-
There is an issue that you overlook here and it is the successful
composition of security models. While your idea is appealing it presents
several problems. In your example you have 3 models with 3 policies.
AppArmor which has its own port security mechanisms is a MAC model that
from what I have seen appears to have a targeted least privilege policy.
This means that AppArmor picks applications it wishes to secure and
makes sure it can't do anything except what it needs to get its job
done. Your module multiadm takes a user which is completely orthogonal
to the concepts that AppArmor uses and gives him extra privileges. From
what I have read and correct me if I am wrong portac deals with users
instead of programs. Now lets try to reconcile this in a way that is
sane to the user/administrator.
Apparmor wants to lock down some application, it gives the application
access to a particular port, and the minimal set of privileges needed to
execute the application. Since Apparmor is "easy to use" (note the
quotes are to indicate they aren't my words not sarcasm) and SUSE comes
with a targeted policy the user isn't concerned with it. Now multiadm
comes along and an administrator wishes to grant extra rights to a user.
This is fine with multiadm alone since it is the main security module,
however we now have to compose this with AppArmor. So an administrator
runs into an error running his application. Is this because his user
isn't granted the proper escalated privileges? Is it because AppArmor
needs an extra rule to run the application? It could also be that our
third module has blocked the application because it determined that even
though multiadm specified that the user should have the elevated
privileges to run the application that user shouldn't be able to bind to
that port.
There might be a better example to illustrate the problem however, this
simple example shows the interdependency of three seemingly simple
modules. Imagine what happens when people really let loose and implement
all sorts of crazy ideas and stack them on top of each other. Stacking
works in things such as file systems because we have a clearly defined
interface with fixed solid semantics. You could attempt to do that but
once you have modules that step on each others toes you have to figure
out a way to reconcile that. It seems to me that you're going to
introduce usability problems that are hard to deal with.
Dave Quigley
> -
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
I have written Smack.
I need an LSM infrastructure.
I would prefer the old dynamic version.
I no trouble with the static version.
I think that a dynamic version is more useful, but I didn't want
what I'm doing to have it as a dependency, so I made sure that
it isn't. The debate about the inclusion of Smack can remain
blissfully separate from the dynamic/static LSM debate. This is
by design.
I have had a couple people suggest changes to Smack that would be
very elegently handled as stacked modules. These include "owned"
ports and additional uid restrictions. Since Smack is a MAC module
these other security features are not really appropriate to include
(if you want the Security Monolith there is SELinux) in it, but
certainly make sense to combine with it.
A stacker that does not require module participation could be quite
interesting. In the old day I felt that a security solution had to
include all aspects of control, but today I see the value provided
by independent mechanisms such as IPtables.
Casey Schaufler
[email protected]
Quoting David P. Quigley ([email protected]):
> On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> > On Oct 24 2007 19:59, Simon Arlott wrote:
> > >On 24/10/07 19:51, Jan Engelhardt wrote:
> > >> On Oct 24 2007 19:11, Simon Arlott wrote:
> > >>>
> > >>>* (I've got a list of access rules which are scanned in order until one of
> > >>>them matches, and an array of one bit for every port for per-port default
> > >>>allow/deny - although the latter could be removed.
> > >>>http://svn.lp0.eu/simon/portac/trunk/)
> > >>
> > >> Besides the 'feature' of inhibiting port binding,
> > >> is not this task of blocking connections something for a firewall?
> > >
> > >The firewall blocks incoming connections where appropriate, yes, but it
> > >doesn't stop one user binding to a port that another user expected to be able
> > >to use. "Ownership" of ports (1-1023) shouldn't be something only root (via
> > >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports
> > >below 1024 and it's useful to be able to prevent users from binding to them
> > >too.
> >
> > Indeed.
> >
> >
> > There has been a feature in the security framework that probably did
> > not get much attention. It looks like YAGNI first, but on a closer look,
> > it becomes useful pretty quick - secondary_register.
> >
> > As more and more simple LSM plugins pop up, stacking/chaining by means
> > of secondary_register becomes attractive again, especially if these LSMs
> > target different actions. This is probably the most useful thing why
> > the LSM interface should remain modular:
> >
> > # Secure my files
> > modprobe apparmor
> > # -*- assuming apparmor implemented secondaries -*-
> > # Secure my ports
> > modprobe portac
> > # More rights to users
> > modprobe multiadm
> > # -*- whatever else comes along -*-
>
> There is an issue that you overlook here and it is the successful
> composition of security models. While your idea is appealing it presents
> several problems. In your example you have 3 models with 3 policies.
> AppArmor which has its own port security mechanisms is a MAC model that
> from what I have seen appears to have a targeted least privilege policy.
> This means that AppArmor picks applications it wishes to secure and
> makes sure it can't do anything except what it needs to get its job
> done. Your module multiadm takes a user which is completely orthogonal
> to the concepts that AppArmor uses and gives him extra privileges. From
> what I have read and correct me if I am wrong portac deals with users
> instead of programs. Now lets try to reconcile this in a way that is
> sane to the user/administrator.
>
> Apparmor wants to lock down some application, it gives the application
> access to a particular port, and the minimal set of privileges needed to
> execute the application. Since Apparmor is "easy to use" (note the
> quotes are to indicate they aren't my words not sarcasm) and SUSE comes
> with a targeted policy the user isn't concerned with it. Now multiadm
> comes along and an administrator wishes to grant extra rights to a user.
> This is fine with multiadm alone since it is the main security module,
> however we now have to compose this with AppArmor. So an administrator
> runs into an error running his application. Is this because his user
> isn't granted the proper escalated privileges? Is it because AppArmor
> needs an extra rule to run the application? It could also be that our
> third module has blocked the application because it determined that even
> though multiadm specified that the user should have the elevated
> privileges to run the application that user shouldn't be able to bind to
> that port.
>
> There might be a better example to illustrate the problem however, this
The scariest thing to consider is programs which don't appropriately
handle failure. So I don't know, maybe the system runs a remote logger
to which the multiadm policy gives some extra privs, but now the portac
module prevents it from sending its data. And maybe, since the authors
never saw this failure as possible, the program happens to dump
sensitive data in a public readable place. I *could* be more vague but
it'd be tough :) But you get the idea.
Or, a better example, a privileged program reads some sensitive data -
as allowed by multiadm, writes it to a file, but apparmor prevented it
from chowning the file to the right user before writing, the program
kept writing anyway, and now the calling user hallyn, rather than the
privileged user sensitive_log_t, owns the file.
I ran into examples of this with the stacker module. For instance
suddenly the capability module had to be changed so that it would allow
selinux xattrs to be written - leaving that arbitration to selinux.
That hadn't been necessary before since selinux simply didn't explicitly
call the secondary->inode_setxattr() hook.
Note I'm not arguing for or against, only arguing for caution :)
-serge
On Oct 24 2007 17:02, David P. Quigley wrote:
>>
>> There has been a feature in the security framework that probably did
>> not get much attention. It looks like YAGNI first, but on a closer look,
>> it becomes useful pretty quick - secondary_register.
>>
>> As more and more simple LSM plugins pop up, stacking/chaining by means
>> of secondary_register becomes attractive again, especially if these LSMs
>> target different actions. This is probably the most useful thing why
>> the LSM interface should remain modular:
>>
>> # Secure my files
>> modprobe apparmor
>> # -*- assuming apparmor implemented secondaries -*-
>> # Secure my ports
>> modprobe portac
>> # More rights to users
>> modprobe multiadm
>> # -*- whatever else comes along -*-
>Apparmor wants to lock down some application, it gives the application
>access to a particular port, and the minimal set of privileges needed to
>execute the application. [...]
>however we now have to compose this with AppArmor. So an administrator
>runs into an error running his application. Is this because his user
>isn't granted the proper escalated privileges? Is it because AppArmor
>needs an extra rule to run the application?
Of course, the example I gave assumed that each LSM had disjunctive
features. Apparmor is primarily known for blocking file access,
and portac for blocking bind(2). If one of these gets additionaly
functionality, it would be nice that code gets combined so that
tracking down the piece of code that caused a particular syscall to
say nay is easier to pinpoint.
>It could also be that our third module has blocked the application
>because it determined that even though multiadm specified that the
>user should have the elevated privileges to run the application that
>user shouldn't be able to bind to that port.
>[...] Stacking works in things such as file systems because we have
>a clearly defined interface with fixed solid semantics. You could
>attempt to do that but once you have modules that step on each
>others toes you have to figure out a way to reconcile that.
I agree - if one does not get the magic behind LSM stacking, s/he
should not use it, or learn to use it.
However, if you grasp how it works (probably even easier to learn
than figuring out how to selinux), one should know that a pam_deny.so
even after a pam_permit.so will lock you down. Yeah, it's like PAM
stacking.
On Oct 24 2007 16:37, Serge E. Hallyn wrote:
>
>Or, a better example, a privileged program reads some sensitive data -
>as allowed by multiadm, writes it to a file, but apparmor prevented it
>from chowning the file to the right user before writing,
Interesting find, I should pay attention to that :-)
But - note to dquigley - AFAICS, an LSM needs to _explicitly_ call
the next LSM's function. No one (just a minimal grep in
linux-2.6/security/) besides SELinux does that today. So
while you could load AppArmor ontop of MultiAdm, it would never
be invoked. This is what is known as "sufficient" in PAM parlance.
SELinux OTOH is in "required" mode [again PAM-speak].
--- "David P. Quigley" <[email protected]> wrote:
> On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> > On Oct 24 2007 19:59, Simon Arlott wrote:
> > >On 24/10/07 19:51, Jan Engelhardt wrote:
> > >> On Oct 24 2007 19:11, Simon Arlott wrote:
> > >>>
> > >>>* (I've got a list of access rules which are scanned in order until one
> of
> > >>>them matches, and an array of one bit for every port for per-port
> default
> > >>>allow/deny - although the latter could be removed.
> > >>>http://svn.lp0.eu/simon/portac/trunk/)
> > >>
> > >> Besides the 'feature' of inhibiting port binding,
> > >> is not this task of blocking connections something for a firewall?
> > >
> > >The firewall blocks incoming connections where appropriate, yes, but it
> > >doesn't stop one user binding to a port that another user expected to be
> able
> > >to use. "Ownership" of ports (1-1023) shouldn't be something only root
> (via
> > >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports
>
> > >below 1024 and it's useful to be able to prevent users from binding to
> them
> > >too.
> >
> > Indeed.
> >
> >
> > There has been a feature in the security framework that probably did
> > not get much attention. It looks like YAGNI first, but on a closer look,
> > it becomes useful pretty quick - secondary_register.
> >
> > As more and more simple LSM plugins pop up, stacking/chaining by means
> > of secondary_register becomes attractive again, especially if these LSMs
> > target different actions. This is probably the most useful thing why
> > the LSM interface should remain modular:
> >
> > # Secure my files
> > modprobe apparmor
> > # -*- assuming apparmor implemented secondaries -*-
> > # Secure my ports
> > modprobe portac
> > # More rights to users
> > modprobe multiadm
> > # -*- whatever else comes along -*-
>
> There is an issue that you overlook here and it is the successful
> composition of security models. While your idea is appealing it presents
> several problems. In your example you have 3 models with 3 policies.
> AppArmor which has its own port security mechanisms is a MAC model that
> from what I have seen appears to have a targeted least privilege policy.
> This means that AppArmor picks applications it wishes to secure and
> makes sure it can't do anything except what it needs to get its job
> done. Your module multiadm takes a user which is completely orthogonal
> to the concepts that AppArmor uses and gives him extra privileges. From
> what I have read and correct me if I am wrong portac deals with users
> instead of programs. Now lets try to reconcile this in a way that is
> sane to the user/administrator.
>
> Apparmor wants to lock down some application, it gives the application
> access to a particular port, and the minimal set of privileges needed to
> execute the application. Since Apparmor is "easy to use" (note the
> quotes are to indicate they aren't my words not sarcasm) and SUSE comes
> with a targeted policy the user isn't concerned with it. Now multiadm
> comes along and an administrator wishes to grant extra rights to a user.
> This is fine with multiadm alone since it is the main security module,
> however we now have to compose this with AppArmor. So an administrator
> runs into an error running his application. Is this because his user
> isn't granted the proper escalated privileges? Is it because AppArmor
> needs an extra rule to run the application? It could also be that our
> third module has blocked the application because it determined that even
> though multiadm specified that the user should have the elevated
> privileges to run the application that user shouldn't be able to bind to
> that port.
>
> There might be a better example to illustrate the problem however, this
> simple example shows the interdependency of three seemingly simple
> modules. Imagine what happens when people really let loose and implement
> all sorts of crazy ideas and stack them on top of each other. Stacking
> works in things such as file systems because we have a clearly defined
> interface with fixed solid semantics. You could attempt to do that but
> once you have modules that step on each others toes you have to figure
> out a way to reconcile that. It seems to me that you're going to
> introduce usability problems that are hard to deal with.
>
> Dave Quigley
Two very important things to consider:
The LSM is designed to be a restrictive mechanism. An LSM module
is not allowed to grant access that would be denied by usual
mechanisms. There are composition problems, but nothing that is
worse than the problems you have to deal with when a filesystem
is mounted read-only. True, one LSM module could muck with the
data used by another, but that's something you can do today with
setxattr() calls in an application.
Which brings up the second important point. The argument above
has nothing whatever to do with mechanisms provided by the kernel
and everything to do with the privileged applications used to
administer a system. Those applications need to be written so as
to deal properly with unexpected access failures, such as might
be induced by a filesystem mounted read-only or being full. I
am aware of the Holy Grail of a security package that does not
interfere with the operation of "normal" administration. How close
you can come to that in independent of wether your kernel is
an integrated "security solution" or a collection of composed
modules.
This discussion is amazingly disconnected from the issues of LSM.
Casey Schaufler
[email protected]
On Wed, 2007-10-24 at 23:51 +0200, Jan Engelhardt wrote:
> On Oct 24 2007 16:37, Serge E. Hallyn wrote:
> >
> >Or, a better example, a privileged program reads some sensitive data -
> >as allowed by multiadm, writes it to a file, but apparmor prevented it
> >from chowning the file to the right user before writing,
>
> Interesting find, I should pay attention to that :-)
>
> But - note to dquigley - AFAICS, an LSM needs to _explicitly_ call
> the next LSM's function. No one (just a minimal grep in
> linux-2.6/security/) besides SELinux does that today. So
> while you could load AppArmor ontop of MultiAdm, it would never
> be invoked. This is what is known as "sufficient" in PAM parlance.
> SELinux OTOH is in "required" mode [again PAM-speak].
True but if we are talking about a true stackable architecture calling
down to your lower component shouldn't be an option it should be a
requirement of the semantics. I would hate to think some module which is
a subset of the restrictiveness of another could override it because its
"sufficient". If that was the case I could load in a module which just
returns 0 for everything and make it "sufficient" bypassing every other
module. This also introduces ordering dependencies. If you install
MultiAdm before AppArmor or SELinux and make it "sufficient" then you
defeated the point of having AppArmor or SELinux installed in the first
place.
Dave
> -
> 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/
On Wed, 2007-10-24 at 14:58 -0700, Casey Schaufler wrote:
> --- "David P. Quigley" <[email protected]> wrote:
>
> > On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> > > On Oct 24 2007 19:59, Simon Arlott wrote:
> > > >On 24/10/07 19:51, Jan Engelhardt wrote:
> > > >> On Oct 24 2007 19:11, Simon Arlott wrote:
> > > >>>
> > > >>>* (I've got a list of access rules which are scanned in order until one
> > of
> > > >>>them matches, and an array of one bit for every port for per-port
> > default
> > > >>>allow/deny - although the latter could be removed.
> > > >>>http://svn.lp0.eu/simon/portac/trunk/)
> > > >>
> > > >> Besides the 'feature' of inhibiting port binding,
> > > >> is not this task of blocking connections something for a firewall?
> > > >
> > > >The firewall blocks incoming connections where appropriate, yes, but it
> > > >doesn't stop one user binding to a port that another user expected to be
> > able
> > > >to use. "Ownership" of ports (1-1023) shouldn't be something only root
> > (via
> > > >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports
> >
> > > >below 1024 and it's useful to be able to prevent users from binding to
> > them
> > > >too.
> > >
> > > Indeed.
> > >
> > >
> > > There has been a feature in the security framework that probably did
> > > not get much attention. It looks like YAGNI first, but on a closer look,
> > > it becomes useful pretty quick - secondary_register.
> > >
> > > As more and more simple LSM plugins pop up, stacking/chaining by means
> > > of secondary_register becomes attractive again, especially if these LSMs
> > > target different actions. This is probably the most useful thing why
> > > the LSM interface should remain modular:
> > >
> > > # Secure my files
> > > modprobe apparmor
> > > # -*- assuming apparmor implemented secondaries -*-
> > > # Secure my ports
> > > modprobe portac
> > > # More rights to users
> > > modprobe multiadm
> > > # -*- whatever else comes along -*-
> >
> > There is an issue that you overlook here and it is the successful
> > composition of security models. While your idea is appealing it presents
> > several problems. In your example you have 3 models with 3 policies.
> > AppArmor which has its own port security mechanisms is a MAC model that
> > from what I have seen appears to have a targeted least privilege policy.
> > This means that AppArmor picks applications it wishes to secure and
> > makes sure it can't do anything except what it needs to get its job
> > done. Your module multiadm takes a user which is completely orthogonal
> > to the concepts that AppArmor uses and gives him extra privileges. From
> > what I have read and correct me if I am wrong portac deals with users
> > instead of programs. Now lets try to reconcile this in a way that is
> > sane to the user/administrator.
> >
> > Apparmor wants to lock down some application, it gives the application
> > access to a particular port, and the minimal set of privileges needed to
> > execute the application. Since Apparmor is "easy to use" (note the
> > quotes are to indicate they aren't my words not sarcasm) and SUSE comes
> > with a targeted policy the user isn't concerned with it. Now multiadm
> > comes along and an administrator wishes to grant extra rights to a user.
> > This is fine with multiadm alone since it is the main security module,
> > however we now have to compose this with AppArmor. So an administrator
> > runs into an error running his application. Is this because his user
> > isn't granted the proper escalated privileges? Is it because AppArmor
> > needs an extra rule to run the application? It could also be that our
> > third module has blocked the application because it determined that even
> > though multiadm specified that the user should have the elevated
> > privileges to run the application that user shouldn't be able to bind to
> > that port.
> >
> > There might be a better example to illustrate the problem however, this
> > simple example shows the interdependency of three seemingly simple
> > modules. Imagine what happens when people really let loose and implement
> > all sorts of crazy ideas and stack them on top of each other. Stacking
> > works in things such as file systems because we have a clearly defined
> > interface with fixed solid semantics. You could attempt to do that but
> > once you have modules that step on each others toes you have to figure
> > out a way to reconcile that. It seems to me that you're going to
> > introduce usability problems that are hard to deal with.
> >
> > Dave Quigley
>
> Two very important things to consider:
>
> The LSM is designed to be a restrictive mechanism. An LSM module
> is not allowed to grant access that would be denied by usual
> mechanisms. There are composition problems, but nothing that is
> worse than the problems you have to deal with when a filesystem
> is mounted read-only. True, one LSM module could muck with the
> data used by another, but that's something you can do today with
> setxattr() calls in an application.
>
> Which brings up the second important point. The argument above
> has nothing whatever to do with mechanisms provided by the kernel
> and everything to do with the privileged applications used to
> administer a system. Those applications need to be written so as
> to deal properly with unexpected access failures, such as might
> be induced by a filesystem mounted read-only or being full. I
> am aware of the Holy Grail of a security package that does not
> interfere with the operation of "normal" administration. How close
> you can come to that in independent of wether your kernel is
> an integrated "security solution" or a collection of composed
> modules.
>
> This discussion is amazingly disconnected from the issues of LSM.
This branch of the tree seems to have gone in a direction similar to the
stackable netfilter like architecture that was suggested by someone last
time this came up.
>
>
> Casey Schaufler
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 24, 2007 at 07:11:17PM +0100, Simon Arlott wrote:
> On 24/10/07 13:55, Adrian Bunk 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?
>
> No, because the interface for configuring it would be rejected... I have
> a /proc file which I write a binary configuration file to. This works
> fine for me but it would take a lot of work to write a proper interface
> - which I'm still not sure how to do*.
>...
Generally, the goal is to get external modules included into the kernel.
You want to be able to have this functionality and you do not want to
use SELinux for it.
But instead of working on getting your code into the kernel you are
requesting that an API making it easier for you to maintain it
externally comes back.
There are other points in this thread that might or might not warrant
making LSM modular again, but even though it might sound harsh breaking
external modules and thereby making people aware that their code should
get into the kernel is IMHO a positive point.
> 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
--- Adrian Bunk <[email protected]> wrote:
> ...
>
> There are other points in this thread that might or might not warrant
> making LSM modular again, but even though it might sound harsh breaking
> external modules and thereby making people aware that their code should
> get into the kernel is IMHO a positive point.
Those proposing LSM modules over the past couple years have
been treated most harshly. I have personally taken the least
flak of anyone on my proposal, and at that there have been
times where I felt like pulling out the #5 clue stick and
taking a few swings. It's no wonder that people are afraid
to suggest a module. I didn't do it until I had combed through
the archives and prepared answers for the most common attacks.
I hope that Smack moving forward will defuse some of the bad
vibes that have clouded the LSM for so long. I don't blame
anyone who kept their module to themself given the hostility
which even successful products have encountered.
And don't give me the old "LKML is a tough crowd" feldercarb.
Security modules have been much worse. Innovation, even in
security, is a good thing and treating people harshly, even
"for their own good", is an impediment to innovation.
Casey Schaufler
[email protected]
On Oct 24 2007 18:02, David P. Quigley wrote:
>>
>> But an LSM needs to _explicitly_ call the next LSM's function. No
>> one (just a minimal grep in linux-2.6/security/) besides SELinux
>> does that today. So while you could load AppArmor ontop of
>> MultiAdm, it would never be invoked. This is what is known as
>> "sufficient" in PAM parlance.
>
>I would hate to think some module which is a subset of the
>restrictiveness of another could override it because its
>"sufficient". If that was the case I could load in a module which
>just returns 0 for everything and make it "sufficient" bypassing
>every other module. This also introduces ordering dependencies. If
>you install MultiAdm before AppArmor or SELinux and make it
>"sufficient" then you defeated the point of having AppArmor or
>SELinux installed in the first place.
If I had to run mtadm and aa alongside each other, I would put aa
into the "secondary" LSM slot.
A number of people have said by now that LSM is supposed to be a
restrict-my-rights block of code. As such, I would put the special,
tiny, give-me-rights code at the front so that it be executed first.
This is what would be intended with mtadm. It really just gives you a
few caps when switching to UID 900 (or whatever), just as Linux
traditionally gives you full caps when switching to UID 0 (e.g. by
executing setuid files). From there on, it is just restrictions, and
the order in which LSMs restrict your actions is probably not so
important as long as they do restrict it.
Thankfully, Linux capabilities are so strangely designed that they
actually become useful - they give you so much power that you _can_
only restrict things afterwards again :-)
On Wed, Oct 24, 2007 at 03:58:02PM -0700, Casey Schaufler wrote:
>
> --- Adrian Bunk <[email protected]> wrote:
>
> > ...
> >
> > There are other points in this thread that might or might not warrant
> > making LSM modular again, but even though it might sound harsh breaking
> > external modules and thereby making people aware that their code should
> > get into the kernel is IMHO a positive point.
>
> Those proposing LSM modules over the past couple years have
> been treated most harshly. I have personally taken the least
> flak of anyone on my proposal, and at that there have been
> times where I felt like pulling out the #5 clue stick and
> taking a few swings. It's no wonder that people are afraid
> to suggest a module. I didn't do it until I had combed through
> the archives and prepared answers for the most common attacks.
> I hope that Smack moving forward will defuse some of the bad
> vibes that have clouded the LSM for so long. I don't blame
> anyone who kept their module to themself given the hostility
> which even successful products have encountered.
>
> And don't give me the old "LKML is a tough crowd" feldercarb.
> Security modules have been much worse. Innovation, even in
> security, is a good thing and treating people harshly, even
> "for their own good", is an impediment to innovation.
What I'm giving you is "Linus has decreed there can be LSMs other than
SELinux."
Getting LSMs included should no longer be harder than for other
parts of the kernel.
And don't get me wrong, I'm not saying my point should decide this
discussion. It's simply the point that making it harder for external
code also has advantages.
> Casey Schaufler
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
On Thu, 25 Oct 2007, Adrian Bunk wrote:
>
> What I'm giving you is "Linus has decreed there can be LSMs other than
> SELinux."
>
> Getting LSMs included should no longer be harder than for other
> parts of the kernel.
Well, despite my heart-felt feelings that we should support different
people in trying out different things, one of the issues is also that I'm
obviously not myself a security person. I can "decree" all I want, but in
the end, I really want the people *involved* to merge security stuff.
Right now Chris Wrigt is the documented maintainer for LSM, and quite
frankly, I do not want to take it over. I really really really hope that
people that are interested in security can work this thing out, and my
only requirement is that it doesn't end up being any kind of force-feeding
of opinions and ideas, since clearly there is tons of room for
disagreement in the area..
Do other people want to stand up and be "LSM maintainers" in the sense
that they also end up being informed members who can also stand up for new
modules and help merge them, rather than just push the existing one(s)?
Chris? Casey? Crispin?
[ Ie there's the "core LSM hooks" on one side, but there's also the "what
modules make any sense at all to merge?" on the other, and I really
don't have the expertise to make any sensible judgements except for the
pure "process" judgement that we should not hardcode things to just one
module! ]
Linus
* Casey Schaufler ([email protected]) wrote:
> And don't give me the old "LKML is a tough crowd" feldercarb.
> Security modules have been much worse. Innovation, even in
> security, is a good thing and treating people harshly, even
> "for their own good", is an impediment to innovation.
I agree that innovation is critical to the success of Linux, and security
is not immune to that. The trouble is that most of the security modules
that have come forward have had some real serious shortcomings. I do
believe it is prudent to keep in-tree security sensitive code under
high scrutiny because we do not want to create security holes by adding
problematic security code.
thanks,
-chris
On 10/24/07, Chris Wright <[email protected]> wrote:
> * Casey Schaufler ([email protected]) wrote:
> > And don't give me the old "LKML is a tough crowd" feldercarb.
> > Security modules have been much worse. Innovation, even in
> > security, is a good thing and treating people harshly, even
> > "for their own good", is an impediment to innovation.
>
> I agree that innovation is critical to the success of Linux, and security
> is not immune to that. The trouble is that most of the security modules
> that have come forward have had some real serious shortcomings.
Key-based masterlocks are easily broken with freon, and their combo
locks are easily brute-forced in about ten minutes. Yet, I'll still
use them to lock up my bike and garage.
The idea that poor security is worse than no security is fallacious,
and not backed up by common experience.
> I do
> believe it is prudent to keep in-tree security sensitive code under
> high scrutiny because we do not want to create security holes by adding
> problematic security code.
If security code actively *adds* holes, then that's obviously a deal breaker.
--- Linus Torvalds <[email protected]> wrote:
>
>
> On Thu, 25 Oct 2007, Adrian Bunk wrote:
> >
> > What I'm giving you is "Linus has decreed there can be LSMs other than
> > SELinux."
> >
> > Getting LSMs included should no longer be harder than for other
> > parts of the kernel.
>
> Well, despite my heart-felt feelings that we should support different
> people in trying out different things, one of the issues is also that I'm
> obviously not myself a security person. I can "decree" all I want, but in
> the end, I really want the people *involved* to merge security stuff.
>
> Right now Chris Wrigt is the documented maintainer for LSM, and quite
> frankly, I do not want to take it over. I really really really hope that
> people that are interested in security can work this thing out, and my
> only requirement is that it doesn't end up being any kind of force-feeding
> of opinions and ideas, since clearly there is tons of room for
> disagreement in the area..
>
> Do other people want to stand up and be "LSM maintainers" in the sense
> that they also end up being informed members who can also stand up for new
> modules and help merge them, rather than just push the existing one(s)?
> Chris? Casey? Crispin?
Count me in.
> [ Ie there's the "core LSM hooks" on one side, but there's also the "what
> modules make any sense at all to merge?" on the other, and I really
> don't have the expertise to make any sensible judgements except for the
> pure "process" judgement that we should not hardcode things to just one
> module! ]
>
> Linus
> -
> 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/
>
>
>
Casey Schaufler
[email protected]
I have different deal breakers.
If a LSM is something simple/commonly required it should be made like
posix file capability's provided to all to use. Sorry to say I see
the file protection in apparmor as something everyone should be able
to use at will like posix file capability's. All enforcement features
should be common.
I see a LSM as a director commander its reason for existence is to
read security configs and hand them permissions and respond to
problems. Any enforcement should be default in kernel.
So LSM could be roll based, mac or any other model. Current problem
enforcement and guiding are mixed up in one block. So evolution is
not happening.
The enforcing bits of LSM's should be a simple no brainier addons to
the Linux kernel. The problem is at moment they are mixed up with Mac
.... A security model to use has to be picked to suit job. Role
Based can be Better than Mac and Mac can be better than Role based.
It all depends on what you are defending.
Thing common all need to protect suid, file access, network access...
The bits you need to defend don't change if or if not you are running
a LSM. So why are these bits bottled up inside LSM forcing people to
choose the wrong security model for there task to get protection at
times.
There can never be one LSM to do every job. But the big but all the
common bits to protect every job could be in kernel. Only thing
missing is the director.
This is exactly the same problem Virtual Server solutions had when
then wanted to get into the kernel. At least the Virtual Server
solutions were not as pig headed as some of the LSM guys about it.
Where its all in or not in at all. Little bits into kernel is better
than nothing.
Really this will sound bad if I had my way I would kick all LSM's out
of the main kernel tree until they learn to work with each other to
share bits. We don't need 10 copies of protect files from access. Or
10 copies of limit what .so a application and interface with and so
on.
It worked with Virtual Servers to get them to sit down and start
talking. What we really need working on is system wide security. No
bothering a lot about the little box of LSM.
Yes I am not nice to LSM. I see them as bitrot. They are going to
cause containers problems in there current form as containers evolve.
They are not improving the base line security level. Yes selinux
saying make me default to improve secuity says that in selinux there
are parts that should be chopped out and made default. But since it
contains a security model it cannot be all made default because it
just will not fit everywhere.
Basically a LSM should make it simpler to run security tight. The big
all mighty but it should not alter achievable security. If its
altering achievable security main kernel is missing features and
someone needs to slice and dice that LSM.
Peter Dolding
--- Chris Wright <[email protected]> wrote:
> * Casey Schaufler ([email protected]) wrote:
> > And don't give me the old "LKML is a tough crowd" feldercarb.
> > Security modules have been much worse. Innovation, even in
> > security, is a good thing and treating people harshly, even
> > "for their own good", is an impediment to innovation.
>
> I agree that innovation is critical to the success of Linux, and security
> is not immune to that. The trouble is that most of the security modules
> that have come forward have had some real serious shortcomings. I do
> believe it is prudent to keep in-tree security sensitive code under
> high scrutiny because we do not want to create security holes by adding
> problematic security code.
I agree that security code does need to provide security. What we
need to get away from is the automatic attacks that are based on 20th
century computer system assumptions. Things like "name based access
control is rediculous", and "a module can't be any good if it doesn't
deal with all objects", or "the granularity isn't fine enough". Look
at TOMOYO. It's chuck full of good ideas. Why spend so much energy
badgering them about not dealing with sockets? How about helping the
AppArmor crew come up with acceptable implementations rather than
whinging about the evils of hard links? And maybe, just maybe, we can
get away from the inevitable claim that you could do that with a few
minutes work in SELinux policy, but only if you're a security
professional of course.
Sure, some LSM proposals will be lousy, and some really will be
better done as an SELinux policy module. Some will even have merit
but require unreasonable interface changes. As people who care
about security (y'all who are only from the LKML are excused) it
is our obligation to look beyond the preconceived notions of what
is and isn't secure. Security is subjective. It's how you feel
about it.
Casey Schaufler
[email protected]
* Linus Torvalds ([email protected]) wrote:
> Do other people want to stand up and be "LSM maintainers" in the sense
> that they also end up being informed members who can also stand up for new
> modules and help merge them, rather than just push the existing one(s)?
> Chris? Casey? Crispin?
Stephen and James, despite their clear bias towards SELinux, do try to
give good feedback. But you are right, there's not enough active help
for people trying to make a contribution to get their code in shape.
Many of the modules that come along have been misguided conceptually,
but I think that e.g. apparmor, tomoyo, smack could use that kind
of constructive help to get into final mergable shape. Personally,
I haven't spent nearly enough time reviewing those, my apologies to
those developers. So, yes, help is welcome.
thanks,
-chris
> The idea that poor security is worse than no security is fallacious,
> and not backed up by common experience.
There is a ton of evidence both in computing and outside of it which
shows that poor security can be very much worse than no security at all.
In particular stuff which makes users think they are secure but is
worthless is very dangerous indeed.
When you know that security is limited you act appropriately, when you
believe security is good but it is not you take inappropriate risks and
get badly burned.
Alan
On Wed, 24 Oct 2007, Serge E. Hallyn wrote:
> The scariest thing to consider is programs which don't appropriately
> handle failure. So I don't know, maybe the system runs a remote logger
> to which the multiadm policy gives some extra privs, but now the portac
> module prevents it from sending its data. And maybe, since the authors
> never saw this failure as possible, the program happens to dump
> sensitive data in a public readable place. I *could* be more vague but
> it'd be tough :) But you get the idea.
>
> Or, a better example, a privileged program reads some sensitive data -
> as allowed by multiadm, writes it to a file, but apparmor prevented it
> from chowning the file to the right user before writing, the program
> kept writing anyway, and now the calling user hallyn, rather than the
> privileged user sensitive_log_t, owns the file.
>
> I ran into examples of this with the stacker module. For instance
> suddenly the capability module had to be changed so that it would allow
> selinux xattrs to be written - leaving that arbitration to selinux.
> That hadn't been necessary before since selinux simply didn't explicitly
> call the secondary->inode_setxattr() hook.
>
> Note I'm not arguing for or against, only arguing for caution :)
this sort of problem is possible with just a single LSM.
remember that unix doesn't try to make it impossible for the system owner
to hang himself, becouse there are many other cases where the rope is used
productivly. don't let the possibility that things can be done wrong
prevent other people from being creative in ways that you never thought
of.
David Lang
On Thu, 25 Oct 2007, Alan Cox wrote:
>> The idea that poor security is worse than no security is fallacious,
>> and not backed up by common experience.
>
> There is a ton of evidence both in computing and outside of it which
> shows that poor security can be very much worse than no security at all.
> In particular stuff which makes users think they are secure but is
> worthless is very dangerous indeed.
there is also pleanty of evidence that you don't have to be perfect to be
good enough.
in addition security is useually traded off for something else
(useability, administrative effort, money, etc) and depending on what's
being protected the cost that's appropriate is going to be different.
> When you know that security is limited you act appropriately, when you
> believe security is good but it is not you take inappropriate risks and
> get badly burned.
This is very true, but the solution isn't to try and eliminate everything
other then perfect security, it's to properly document the limitations of
various options and educate people about them.
David Lang
On Wed, 24 Oct 2007 17:41:28 -0700
Chris Wright <[email protected]> wrote:
> * Linus Torvalds ([email protected]) wrote:
> > Do other people want to stand up and be "LSM maintainers" in the
> > sense that they also end up being informed members who can also
> > stand up for new modules and help merge them, rather than just push
> > the existing one(s)? Chris? Casey? Crispin?
>
> Stephen and James, despite their clear bias towards SELinux, do try to
> give good feedback. But you are right, there's not enough active help
> for people trying to make a contribution to get their code in shape.
> Many of the modules that come along have been misguided conceptually,
> but I think that e.g. apparmor, tomoyo, smack could use that kind
> of constructive help to get into final mergable shape. Personally,
> I haven't spent nearly enough time reviewing those, my apologies to
> those developers. So, yes, help is welcome.
>
I'll be happy to help out; I'd consider my self neutral in this space
not having worked with any of the LSM out there. I do think we need to
be somewhat critical to what we accept; we should at least be able to
filter out "pretend security" somehow. (this is not the same as saying
that you're bad if you only provide a limited security, in the
contrary, I strongly believe in simple pieces. What I mean is that we
should be critical to things that appear/claim to be strong but are
not).
Secondly, we should make sure that no new holes are added (the original
SMACK series suffered from this, Al Viro helped getting that reviewed
bigtime).
In addition we probably should strive to getting some sort of rough
"this is sort of where we draw the line" guideline set up, just to keep
things more objective.
(Oh and of course, if a security module is deeply involved in another
kernel subsystem, say networking or the VFS, very obviously we should
consult and listen to the respective maintainers of that subsystem; LSM
is not there to be a big hook to bypass the process of well maintained
subsystems)
On Oct 24, 2007, at 17:37:04, Serge E. Hallyn wrote:
> The scariest thing to consider is programs which don't
> appropriately handle failure. So I don't know, maybe the system
> runs a remote logger to which the multiadm policy gives some extra
> privs, but now the portac module prevents it from sending its
> data. And maybe, since the authors never saw this failure as
> possible, the program happens to dump sensitive data in a public
> readable place. I *could* be more vague but it'd be tough :) But
> you get the idea.
Well, there *was* that problem with sendmail where it did not
properly check the result of setuid() and just assumed it had
succeeded. So instead of running as "smtpd" it was running as
"root". Not a happy memory.
Cheers,
Kyle Moffett
On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
[....]
> Key-based masterlocks are easily broken with freon, and their combo
> locks are easily brute-forced in about ten minutes. Yet, I'll still
> use them to lock up my bike and garage.
The question is what the security threat is and the value of the secured
items.
> The idea that poor security is worse than no security is fallacious,
> and not backed up by common experience.
The common experience is, that common people just *feel* safer (just
because they have poor security).
With no security, they know that there is no security. With poor
security, they do not know (or can deny) that they have next to no real
security.
The prime example here is the usual (so-called) "personal firewall" on
Windows where people work normally as "administrator".
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
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....
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/
On Wed, October 24, 2007 22:02, David P. Quigley wrote:
> Apparmor wants to lock down some application, it gives the application
> access to a particular port, and the minimal set of privileges needed to
> execute the application. Since Apparmor is "easy to use" (note the
> quotes are to indicate they aren't my words not sarcasm) and SUSE comes
> with a targeted policy the user isn't concerned with it. Now multiadm
> comes along and an administrator wishes to grant extra rights to a user.
> This is fine with multiadm alone since it is the main security module,
> however we now have to compose this with AppArmor. So an administrator
> runs into an error running his application. Is this because his user
> isn't granted the proper escalated privileges? Is it because AppArmor
> needs an extra rule to run the application? It could also be that our
> third module has blocked the application because it determined that even
> though multiadm specified that the user should have the elevated
> privileges to run the application that user shouldn't be able to bind to
> that port.
>
> There might be a better example to illustrate the problem however, this
> simple example shows the interdependency of three seemingly simple
> modules. Imagine what happens when people really let loose and implement
> all sorts of crazy ideas and stack them on top of each other. Stacking
> works in things such as file systems because we have a clearly defined
> interface with fixed solid semantics. You could attempt to do that but
> once you have modules that step on each others toes you have to figure
> out a way to reconcile that. It seems to me that you're going to
> introduce usability problems that are hard to deal with.
I agree that it can cause problems, but it's up to the modules themselves
to determine how to combine permissions with their immediate secondary
module.
Instead we now have a static LSM where combining features from one module
means duplicating it in another - then when two modules contain most of
the other's code, but perhaps vastly different configuration mechanisms,
someone will propose removing one of the two...
--
Simon Arlott
On Wed, October 24, 2007 23:31, Adrian Bunk wrote:
> On Wed, Oct 24, 2007 at 07:11:17PM +0100, Simon Arlott wrote:
>> On 24/10/07 13:55, Adrian Bunk 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?
>>
>> No, because the interface for configuring it would be rejected... I have
>> a /proc file which I write a binary configuration file to. This works
>> fine for me but it would take a lot of work to write a proper interface
>> - which I'm still not sure how to do*.
>>...
>
> Generally, the goal is to get external modules included into the kernel.
>
> You want to be able to have this functionality and you do not want to
> use SELinux for it.
SELinux couldn't do it when I wrote my own module, it may do now but I
haven't checked - that's also far too much extra configuration overhead
to do something relatively simple.
> But instead of working on getting your code into the kernel you are
> requesting that an API making it easier for you to maintain it
> externally comes back.
It's also much harder to maintain it internally too since it can no
longer be compiled as a module. If it were possible to have to make LSM
usable as a module but without secondary support, that would make
development easier - although secondary support is so trivial I doubt
it makes a difference to the possibility of allowing it to be compiled
as a module again.
> There are other points in this thread that might or might not warrant
> making LSM modular again, but even though it might sound harsh breaking
> external modules and thereby making people aware that their code should
> get into the kernel is IMHO a positive point.
You're only going to be forcing me to spend *my* time developing it into
something that could be accepted into the kernel when it works fine for
me already. Then I'd have to convince the LSM maintainer(s) that it
should be merged - this isn't like an external hardware driver where
there's no existing support in the kernel.
>> Simon Arlott
>
> cu
> Adrian
--
Simon Arlott
On 10/25/07, Bernd Petrovitsch <[email protected]> wrote:
> On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
> [....]
> > Key-based masterlocks are easily broken with freon, and their combo
> > locks are easily brute-forced in about ten minutes. Yet, I'll still
> > use them to lock up my bike and garage.
>
> The question is what the security threat is and the value of the secured
> items.
>
> > The idea that poor security is worse than no security is fallacious,
> > and not backed up by common experience.
>
> The common experience is, that common people just *feel* safer (just
> because they have poor security).
Do you lock your bike up when you leave it lying around? My point is
that real security comes in layers, not one perfect solution that will
always work everywhere for everyone. The latter is a pipe-dream.
> With no security, they know that there is no security. With poor
> security, they do not know (or can deny) that they have next to no real
> security.
The fallacy here is to believe that just because they have no
security, that it will *in*any*way* change their behavior. I deal with
real users daily, and *they*don't*care*. Further, there's no level of
education that we can instill into the community to make them aware of
the issues and change their habits accordingly, because real users
don't have the background to understand those lessons.
While you can teach them that running an executable from someone they
haven't heard of is obviously bad, they don't know why downloading an
image is potentially dangerous, "it's an image, right?" "Well, there's
these things called buffer overflows..." <eyes glaze over>
Security is not an all or nothing game, it's layers. And we have to
make sure that the layers are usable without taking a course from the
NSA. I'd love to see a poll of the kernel development community to
find out how many use SELinux on their machines, for example.
> The prime example here is the usual (so-called) "personal firewall" on
> Windows where people work normally as "administrator".
So your argument is that if there weren't a personal firewall on
Windows, that a significant number of people would then not run as
Administrator? I beg to differ.
Ray
On Thu, 25 Oct 2007 09:04:57 -0700
"Ray Lee" <[email protected]> wrote:
> Security is not an all or nothing game, it's layers. And we have to
> make sure that the layers are usable without taking a course from the
> NSA. I'd love to see a poll of the kernel development community to
> find out how many use SELinux on their machines, for example.
I absolutely agree it's a layer game.
HOWEVER, even in a layer game we need to have each layer to be
reasonably solid and not just fake security ("snakeoil").
So while I think it is entirely fair to judge a piece of software
against what it intends/claims to do, because other pieces in the layer
game will depend on it to function reasonably well.
So most of the LSM fist-fights have been about disagreement of the
intent; and some about code not living up to its own intend, all mixed
up. Arguing about the intent is less productive imo (as long as it's at
least somewhat reasonable, intend like "I want to add rootkits" doesn't
count obviously), paying attention to check if the code lives up to its
stated intent/purpose on the other hand is immensely useful and needed;
for a given implementation it may mean reducing the scope of the intent
if the implementation just doesn't go as wide as originally thought, or
fixing some issues in the implementation to live up to the intent.
On 10/24/07, Alan Cox <[email protected]> wrote:
> > The idea that poor security is worse than no security is fallacious,
> > and not backed up by common experience.
>
> There is a ton of evidence both in computing and outside of it which
> shows that poor security can be very much worse than no security at all.
(So, I take it that you *don't* lock your bike up, as poor security is
worse than none?)
While I believe you, I'd love to see references as it doesn't match my
day-to-day experience with Win/Mac end-users over the past ten years.
> In particular stuff which makes users think they are secure but is
> worthless is very dangerous indeed.
I have no trouble believing that.
> When you know that security is limited you act appropriately, when you
> believe security is good but it is not you take inappropriate risks and
> get badly burned.
'Inappropriate risks' nowadays is surfing the web and opening up mail
attachments that claim to be movies of dancing bears. I'd argue that
users have a reasonable expectation that these are things that should
'just work,' and be safe, much as normal humans have an expectation
that their car isn't going to explode when they turn the ignition.
Perfect is the enemy of good, or words to that effect, right? My point
is that requiring perfection out of a security framework is a bar
that's going to be awfully difficult to reach (and when it supposedly
has been achieved, as in SELinux, mere mortals find it too troublesome
to run with as it's far too difficult to configure). Security can and
should be done in layers, and what one may miss, another may catch.
Ray
> > There is a ton of evidence both in computing and outside of it which
> > shows that poor security can be very much worse than no security at all.
>
> (So, I take it that you *don't* lock your bike up, as poor security is
> worse than none?)
On the contrary because I know it is not secure I would
a) Insure it
b) Not waste vast amounts of money on a useless expensive lock
c) Make sure the bike looked not worth stealing
d) Take the saddle with me
(or the software versions of that
a) Keep backups
b) Not waste vast amounts of money on bogus security software
c) Keep the system looking uninteresting
d) Encrypt the data)
> 'Inappropriate risks' nowadays is surfing the web and opening up mail
> attachments that claim to be movies of dancing bears. I'd argue that
> users have a reasonable expectation that these are things that should
> 'just work,' and be safe, much as normal humans have an expectation
> that their car isn't going to explode when they turn the ignition.
Yes and its very clear from the things said by politicians that if the
computer software people don't do this soon, the legislators will make
very sure they do by stripping away all the techniques used to hide from
liability for failure.
> Perfect is the enemy of good, or words to that effect, right? My point
> is that requiring perfection out of a security framework is a bar
> that's going to be awfully difficult to reach (and when it supposedly
> has been achieved, as in SELinux, mere mortals find it too troublesome
> to run with as it's far too difficult to configure). Security can and
> should be done in layers, and what one may miss, another may catch.
Absolutely - but those layers should do whatever they do *right* and
really do it, whether they are complex whole system controls like SELinux
or simple network security tools.
Alan
Am 25.10.2007 00:31 schrieb Adrian Bunk:
> Generally, the goal is to get external modules included into the kernel.
> [...] even though it might sound harsh breaking
> external modules and thereby making people aware that their code should
> get into the kernel is IMHO a positive point.
This argument seems to start from the assumption that any externally
maintained kernel code *can* get into the kernel, which doesn't stand
up to reality. Once you admit that there is code which, for very good
reasons, won't ever be accepted into the mainline kernel tree, what you
are saying amounts to: "Code that isn't fit to be included in the
mainline kernel isn't fit to exist at all."
I'm not sure I can agree with that.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
> Am 25.10.2007 00:31 schrieb Adrian Bunk:
> > Generally, the goal is to get external modules included into the kernel.
> > [...] even though it might sound harsh breaking
> > external modules and thereby making people aware that their code should
> > get into the kernel is IMHO a positive point.
>
> This argument seems to start from the assumption that any externally
> maintained kernel code *can* get into the kernel, which doesn't stand
> up to reality. Once you admit that there is code which, for very good
> reasons, won't ever be accepted into the mainline kernel tree, what you
> are saying amounts to: "Code that isn't fit to be included in the
> mainline kernel isn't fit to exist at all."
What kind of code is not accepted into the mainline kernel tree for good
reasons? What are these reasons? What specific code are you talking
about?
I'm trying to compile a list of all known external modules and drivers
and work to get them included in the main kernel tree to help prevent
these kinds of things. If you know of any that are not on the list at:
http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
please feel free to add them, or email me with the needed information
and I will add them to the list.
thanks,
greg k-h
On Thu, 25 Oct 2007, Alan Cox wrote:
>>> There is a ton of evidence both in computing and outside of it which
>>> shows that poor security can be very much worse than no security at all.
>>
>> (So, I take it that you *don't* lock your bike up, as poor security is
>> worse than none?)
>
> On the contrary because I know it is not secure I would
>
> a) Insure it
and the unsurance company would have a clause in the policy that wouldn't
cover you unless you used a lock, becouse they recognise that while it
wouldn't stop everyone there is a large group of potential thieves that it
would stop.
> b) Not waste vast amounts of money on a useless expensive lock
who said the lock was expensive? and while you are not willing to spend
money on a lock you are willing to spend (much more) money on an insurance
policy.
David Lang
> c) Make sure the bike looked not worth stealing
> d) Take the saddle with me
>
> (or the software versions of that
>
> a) Keep backups
> b) Not waste vast amounts of money on bogus security software
> c) Keep the system looking uninteresting
> d) Encrypt the data)
>
>> 'Inappropriate risks' nowadays is surfing the web and opening up mail
>> attachments that claim to be movies of dancing bears. I'd argue that
>> users have a reasonable expectation that these are things that should
>> 'just work,' and be safe, much as normal humans have an expectation
>> that their car isn't going to explode when they turn the ignition.
>
> Yes and its very clear from the things said by politicians that if the
> computer software people don't do this soon, the legislators will make
> very sure they do by stripping away all the techniques used to hide from
> liability for failure.
>
>> Perfect is the enemy of good, or words to that effect, right? My point
>> is that requiring perfection out of a security framework is a bar
>> that's going to be awfully difficult to reach (and when it supposedly
>> has been achieved, as in SELinux, mere mortals find it too troublesome
>> to run with as it's far too difficult to configure). Security can and
>> should be done in layers, and what one may miss, another may catch.
>
> Absolutely - but those layers should do whatever they do *right* and
> really do it, whether they are complex whole system controls like SELinux
> or simple network security tools.
>
> Alan
> -
> 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/
>
Ok lets get to a good point.
Lets define a key bit. What is a good software security lock?
My define is that its available to be used everywhere its needed and
when ever its need without flaw.
This is where most LSM fall in a heap. Because you have to have the
LSM loaded to have its security features and cannot always be mixed
with other LSM it failes the when ever it is needed test.
On top of this most LSM features don't provide any form of direct
control to non admin users or applications to lower there access
rights. So it also fails to be used everywhere its needed.
Since the LSM design itself is flawed in my eyes. These flaws make
it hard for LSM to share tech advantages with each other. LSM are
very much like putting a lock threw the front wheel of a bike. So
the thief removes the front wheel and walks off with the rest of the
bike. The critical data is in the user accounts.
The big thing with most LSM how do they handle security inside a
application on a thread by thread base. They don't reason it gets too
compex without known the internals of the application.
We are talking security here and design of LSM's are not offering the
option max security.
Max security has to get down to a single thread inside a application
with all the security blocking features LSM's offer. Reason a flaw in
that thread could be made completely harmless even that the other
threads in the application has complete system rights.
Idea of Max is to keep application flaws to as minor security flaw as
they could have been. Ie Hopefully no risk because the flaw happened
in a section of code with no rights.
This is virtually imposable for any form of profiling creating
security to ever do(LSM profile based security). What is needed is
application controlled security with profile based security as fail
back. I know this means ripping your LSM parts apart and designing in
application controls. Allowing features to be shared between LSM and
even to be there when the LSM that feature came from is not being
used.
First goal should not be to get a LSM static linked into kernel or
anything else bar getting the security system to a point that max
security is on the table if people want it.
I will say this again in my eyes LSM's should be thrown out of the
kernel completely because they are only offering fake max security.
Selinux and other LSM's on max is not even close to what should be
offered.
Basically Linux is a sitting duck for data thief third party that
steal from the users home directory personal information. And its
not like application developers are being given the tools to prevent
that. Cost and loss does not start only when applications normal
profile of access is breached. It starts way before that.
Peter Dolding
On Oct 25 2007 19:56, Greg KH wrote:
>
>I'm trying to compile a list of all known external modules and drivers
>and work to get them included in the main kernel tree to help prevent
>these kinds of things. If you know of any that are not on the list at:
> http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>please feel free to add them, or email me with the needed information
>and I will add them to the list.
Do I have to at least try to submit it to LKML first before it is
even considered for the OOT wiki page? :-)
On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
>> Am 25.10.2007 00:31 schrieb Adrian Bunk:
>> > Generally, the goal is to get external modules included into the kernel.
>> > [...] even though it might sound harsh breaking
>> > external modules and thereby making people aware that their code should
>> > get into the kernel is IMHO a positive point.
>>
>> This argument seems to start from the assumption that any externally
>> maintained kernel code *can* get into the kernel, which doesn't stand
>> up to reality. Once you admit that there is code which, for very good
>> reasons, won't ever be accepted into the mainline kernel tree, what you
>> are saying amounts to: "Code that isn't fit to be included in the
>> mainline kernel isn't fit to exist at all."
>
> What kind of code is not accepted into the mainline kernel tree for good
> reasons?
- proprietary code
- unmaintained code
- code conflicting with existing kernel structure or policy
- code in which the concerned subsystem maintainers see no benefit
- code which its author is unable and/or unwilling to convert to
kernel coding standards
- code whose author is unable and/or unwilling to defend it on LKML
> What are these reasons?
The details vary, but the fundamental reason is always the same: to
maintain a sufficient level of code quality in the kernel. Point in
case, the recent discussion whether drivers not supporting
suspend/resume should be refused to merge.
> What specific code are you talking about?
Some examples, in no particular order: Reiser4, AppArmor, VMware,
the staircase deadline scheduler, the first version of ser_gigaset,
the Matrox HAL module, SuSE's "taint extension". Yes, some of these
are in the kernel now, or have been superseded by other code that
is, but that doesn't invalidate my concern.
> I'm trying to compile a list of all known external modules and drivers
> and work to get them included in the main kernel tree to help prevent
> these kinds of things. If you know of any that are not on the list at:
> http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
> please feel free to add them, or email me with the needed information
> and I will add them to the list.
That's certainly helpful, but I still think there will always be
a number of external modules that cannot be merged right now or at
all, and deliberately making life difficult for out-of-tree code
maintainers in order to coerce them into submitting their code for
inclusion in the kernel will not work, it'll only create bad
feelings.
Thanks,
Tilman
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
Jan Engelhardt <[email protected]> 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/[email protected]/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
On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> > I'm trying to compile a list of all known external modules and drivers
> > and work to get them included in the main kernel tree to help prevent
> > these kinds of things. If you know of any that are not on the list at:
> > http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
> > please feel free to add them, or email me with the needed information
> > and I will add them to the list.
>
> That's certainly helpful, but I still think there will always be
> a number of external modules that cannot be merged right now or at
> all, and deliberately making life difficult for out-of-tree code
> maintainers in order to coerce them into submitting their code for
> inclusion in the kernel will not work, it'll only create bad
> feelings.
Do you have examples of proof of this? Read
Documentation/stable_api_nonsense.txt for how we already make
out-of-tree code developer's lives hell :)
thanks,
greg k-h
On Fri, Oct 26, 2007 at 09:09:05AM +0200, Jan Engelhardt wrote:
>
> On Oct 25 2007 19:56, Greg KH wrote:
> >
> >I'm trying to compile a list of all known external modules and drivers
> >and work to get them included in the main kernel tree to help prevent
> >these kinds of things. If you know of any that are not on the list at:
> > http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
> >please feel free to add them, or email me with the needed information
> >and I will add them to the list.
>
> Do I have to at least try to submit it to LKML first before it is
> even considered for the OOT wiki page? :-)
No, you can go hide on your own, that's what the majority of projects on
that page have done :)
But of course, it would be good for you to at least submit it and get
feedback. Or, if you don't want to do it, the linuxdriverproject
developers would be glad to help you out...
thanks,
greg k-h
On 26/10/07 16:58, Greg KH wrote:
> On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
>> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
>> > I'm trying to compile a list of all known external modules and drivers
>> > and work to get them included in the main kernel tree to help prevent
>> > these kinds of things. If you know of any that are not on the list at:
>> > http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>> > please feel free to add them, or email me with the needed information
>> > and I will add them to the list.
>>
>> That's certainly helpful, but I still think there will always be
>> a number of external modules that cannot be merged right now or at
>> all, and deliberately making life difficult for out-of-tree code
>> maintainers in order to coerce them into submitting their code for
>> inclusion in the kernel will not work, it'll only create bad
>> feelings.
>
> Do you have examples of proof of this? Read
> Documentation/stable_api_nonsense.txt for how we already make
> out-of-tree code developer's lives hell :)
The change makes it much harder to develop in tree too. Also, this really
needs to be reverted and put in the feature removal schedule... unless
you intend to deliberately make all out of tree LSMs unusable with no
warning and no time to have them added to the kernel? We're already at
2.6.24-rc1.
--
Simon Arlott
On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> > On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
> >> Am 25.10.2007 00:31 schrieb Adrian Bunk:
> >> > Generally, the goal is to get external modules included into the kernel.
> >> > [...] even though it might sound harsh breaking
> >> > external modules and thereby making people aware that their code should
> >> > get into the kernel is IMHO a positive point.
> >>
> >> This argument seems to start from the assumption that any externally
> >> maintained kernel code *can* get into the kernel, which doesn't stand
> >> up to reality. Once you admit that there is code which, for very good
> >> reasons, won't ever be accepted into the mainline kernel tree, what you
> >> are saying amounts to: "Code that isn't fit to be included in the
> >> mainline kernel isn't fit to exist at all."
> >
> > What kind of code is not accepted into the mainline kernel tree for good
> > reasons?
>
> - proprietary code
It's unclear whether distributing not GPL compatible modules is legal
at all.
And they are definitely not "very good reasons" for doing anything in
the kernel.
> - unmaintained code
Unmaintained code in the kernel has a realistic chance of being usable
for 5 years.
Unmaintained external code is quite likely to be unusable after
at most one year.
> - code conflicting with existing kernel structure or policy
> - code in which the concerned subsystem maintainers see no benefit
Let's fix the problems, not work around them.
There is a conflict between getting code included and ensuring some
minimum quality of the kernel, but in many cases we could try better.
And when there's a good reason for a kernel policy, then code that
violates this policy is not a "very good reason" for anything.
> - code which its author is unable and/or unwilling to convert to
> kernel coding standards
> - code whose author is unable and/or unwilling to defend it on LKML
>...
That's their fault, and definitely not a "very good reason" for making
life easier for them.
> Thanks,
> Tilman
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
Greg KH schrieb:
> On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
>> [...] I still think there will always be
>> a number of external modules that cannot be merged right now or at
>> all, and deliberately making life difficult for out-of-tree code
>> maintainers in order to coerce them into submitting their code for
>> inclusion in the kernel will not work, it'll only create bad
>> feelings.
>
> Do you have examples of proof of this?
No proof in the legal, mathematical or scientific sense of the
term, but examples:
- at least one talented kernel developer giving up his work,
until then maintained out of tree, after submitting it for
inclusion in the kernel and taking the ensuing fla^Wdiscussion
on LKML (nothing extraordinary, just the usual lack of
courtesy and respect) too much to heart
- the furious flames on LKML each time someone dares posting
helpful information about getting non-GPL software working
again with the newest kernel version, which will certainly
never achieve inclusion of that software in the kernel but
definitely create bad feelings on both sides (righteous
indignation *is* a bad feeling in my book)
> Read Documentation/stable_api_nonsense.txt for how we already make
> out-of-tree code developer's lives hell :)
Oh yes, that one. A key piece of evidence. Yes, I've read it,
though I sometimes wish I hadn't. Its very title supports my
observation on the creation of bad feelings, and the actual
text doesn't contradict it. (no ":)")
T.
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.
Adrian Bunk schrieb:
> On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
>> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
>>> On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
>>>> [...] Once you admit that there is code which, for very good
>>>> reasons, won't ever be accepted into the mainline kernel tree, what you
>>>> are saying amounts to: "Code that isn't fit to be included in the
>>>> mainline kernel isn't fit to exist at all."
>>> What kind of code is not accepted into the mainline kernel tree for good
>>> reasons?
>> - proprietary code
>
> It's unclear whether distributing not GPL compatible modules is legal
> at all.
We're neither talking about distribution nor legal aspects, but
about existence. But anyway, you seem to agree with me that there
are very good reasons for not including these in the kernel.
> And they are definitely not "very good reasons" for doing anything in
> the kernel.
There is a big difference between "not doing anything to help"
and "actively doing something to make life difficult for". The
former is undoubtedly legitimate. It's the latter we're
discussing here.
>> - unmaintained code
>
> Unmaintained code in the kernel has a realistic chance of being usable
> for 5 years.
>
> Unmaintained external code is quite likely to be unusable after
> at most one year.
Then why is "being unmaintained" being toted as an argument
*against* inclusion in the kernel?
>> - code conflicting with existing kernel structure or policy
>> - code in which the concerned subsystem maintainers see no benefit
>
> Let's fix the problems, not work around them.
That's certainly better, but not always possible. Do you
agree with me that if it isn't, then that's a very good
reason for not including that code in the kernel?
> There is a conflict between getting code included and ensuring some
> minimum quality of the kernel, but in many cases we could try better.
Correct. Again, you appear to agree with my statement that
for some code there are very good reasons not to include it
in the kernel.
> And when there's a good reason for a kernel policy, then code that
> violates this policy is not a "very good reason" for anything.
>> - code which its author is unable and/or unwilling to convert to
>> kernel coding standards
>> - code whose author is unable and/or unwilling to defend it on LKML
>> ...
>
> That's their fault, and definitely not a "very good reason" for making
> life easier for them.
Putting aside the fruitless question of whose fault it is,
is it a "very good reason" for actively making life more
difficult for them than it is already, eg. by gratuitiously
breaking interfaces they rely on for no other "very good
reason" than to discourage out-of-tree development? In other
words, do you think it benefits the Linux community if you
discourage those programmers you've already scared away from
submitting their code to the kernel from continuing their
work off-tree, too? In summary, do you think the world would
be a better place if all the existing out-of-tree modules
just ceased to exist, without any replacement?
T.
Tilman Schmidt wrote about:
> breaking interfaces they rely on for no other "very good
> reason" than to discourage out-of-tree development?
How often did this happen yet?
--
Stefan Richter
-=====-=-=== =-=- ==-==
http://arcgraph.de/sr/
On Sat, Oct 27, 2007 at 04:47:15PM +0200, Tilman Schmidt wrote:
> Adrian Bunk schrieb:
> > On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> >> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> >>> On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
> >>>> [...] Once you admit that there is code which, for very good
> >>>> reasons, won't ever be accepted into the mainline kernel tree, what you
> >>>> are saying amounts to: "Code that isn't fit to be included in the
> >>>> mainline kernel isn't fit to exist at all."
> >>> What kind of code is not accepted into the mainline kernel tree for good
> >>> reasons?
> >> - proprietary code
> >
> > It's unclear whether distributing not GPL compatible modules is legal
> > at all.
>
> We're neither talking about distribution nor legal aspects, but
> about existence. But anyway, you seem to agree with me that there
> are very good reasons for not including these in the kernel.
>
> > And they are definitely not "very good reasons" for doing anything in
> > the kernel.
>
> There is a big difference between "not doing anything to help"
> and "actively doing something to make life difficult for". The
> former is undoubtedly legitimate. It's the latter we're
> discussing here.
Justifying anything with code with not GPL compatible licences has zero
relevance here.
And there's value in making life harder for such modules with
questionable legality. As an example, consider people who experienced
crashes of "the Linux kernel" caused by some binary-only driver.
Not that uncommon e.g. with some graphics drivers.
This harms the reputation of Linux as being stable.
The solution is not to support proprietary drivers, the solution is to
get open source replacements.
>...
> >> - code conflicting with existing kernel structure or policy
> >> - code in which the concerned subsystem maintainers see no benefit
> >
> > Let's fix the problems, not work around them.
>
> That's certainly better, but not always possible. Do you
> agree with me that if it isn't, then that's a very good
> reason for not including that code in the kernel?
No, it's still a reason for fixing the real problem.
> > There is a conflict between getting code included and ensuring some
> > minimum quality of the kernel, but in many cases we could try better.
>
> Correct. Again, you appear to agree with my statement that
> for some code there are very good reasons not to include it
> in the kernel.
But this does not result in any obligation of supporting low quality
external code that destabilizes the kernel of people using it.
If it's low quality code doing something useful - well, how many hundred
people are on Greg's list only waiting for some driver they could write?
> > And when there's a good reason for a kernel policy, then code that
> > violates this policy is not a "very good reason" for anything.
>
> >> - code which its author is unable and/or unwilling to convert to
> >> kernel coding standards
> >> - code whose author is unable and/or unwilling to defend it on LKML
> >> ...
> >
> > That's their fault, and definitely not a "very good reason" for making
> > life easier for them.
>
> Putting aside the fruitless question of whose fault it is,
> is it a "very good reason" for actively making life more
> difficult for them than it is already, eg. by gratuitiously
> breaking interfaces they rely on for no other "very good
> reason" than to discourage out-of-tree development? In other
> words, do you think it benefits the Linux community if you
> discourage those programmers you've already scared away from
> submitting their code to the kernel from continuing their
> work off-tree, too? In summary, do you think the world would
> be a better place if all the existing out-of-tree modules
> just ceased to exist, without any replacement?
With your "without any replacement" you needlessly excluded the
reasonable solution:
The solution is that someone other than the author either takes the
existing external code or rewrites it from scratch, submits it for
inclusion into the kernel, and maintains it there.
Let me repeat that Greg has said he has hundreds of volunteers for such
tasks.
> T.
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
On Sat, Oct 27, 2007 at 04:07:41PM +0200, Tilman Schmidt wrote:
> Greg KH schrieb:
> > On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> >> [...] I still think there will always be
> >> a number of external modules that cannot be merged right now or at
> >> all, and deliberately making life difficult for out-of-tree code
> >> maintainers in order to coerce them into submitting their code for
> >> inclusion in the kernel will not work, it'll only create bad
> >> feelings.
> >
> > Do you have examples of proof of this?
>
> No proof in the legal, mathematical or scientific sense of the
> term, but examples:
>
> - at least one talented kernel developer giving up his work,
> until then maintained out of tree, after submitting it for
> inclusion in the kernel and taking the ensuing fla^Wdiscussion
> on LKML (nothing extraordinary, just the usual lack of
> courtesy and respect) too much to heart
>...
There's one important point to note:
In a project of the size of the Linux kernel (at about 2000 distinct
people contributing code within one year) you will always lose
developers:
If you require too much from code for getting it included you lose some
of the people who develop code.
If you accept code of dubious quality you lose some of the people who
care about the quality of the kernel.
And if you add a stable API for modules with not GPL compatible licences
at least one untalented kernel developer (me) might give up his work.
If your goal is to please all developers you have a goal you can't
achieve.
The only reasonable way is to accept that whatever you do you'll lose
some people and go in the direction you consider the right one.
And the power of open source is that when an open source project gets
into a direction many people dislike they can simply fork it. Consider
e.g. XFree86->X.Org or NetBSD->OpenBSD. And that's nothing bad - either
the forks develop in different directions creating different useful
software or there's an evolutionary contest for the best software.
> T.
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
Adrian Bunk wrote:
> On Sat, Oct 27, 2007 at 04:47:15PM +0200, Tilman Schmidt wrote:
>> There is a big difference between "not doing anything to help"
>> and "actively doing something to make life difficult for". The
>> former is undoubtedly legitimate. It's the latter we're
>> discussing here.
>
> Justifying anything with code with not GPL compatible licences has zero
> relevance here.
>
> And there's value in making life harder for such modules with
> questionable legality. As an example,
[...]
You two are hypothesizing.
- We (most of us) change APIs to improve the kernel.
- We (most of us) contribute to the kernel as a program for people to
run, not as a library for other projects to develop different or
extended kernels? on top of it.
Actually, by providing the code under GPL, full read access to the SCM
for everybody, and public development mailinglists, we make life for
external projects who do their own drivers and kernels as easy as these
unconnected projects could wish for.?
-----
?) Even distributors of Linux kernel packages are encouraged to stay
close to mainline and to feed their changes into mainline, IOW to take
part in the Linux kernel project.
?) Of course if such projects chose to become part of the Linux kernel
project, they would get to enjoy additional bonuses as outlined at the
end of stable_api_nonsense.txt. Sure, becoming part of the project
involves to cooperate, and not everybody wants or can afford to do so.
--
Stefan Richter
-=====-=-=== =-=- ===--
http://arcgraph.de/sr/
Am 28.10.2007 10:25 schrieb Stefan Richter:
> You two are hypothesizing.
No, we're not. We're discussing the very real issue of whether
LSM should be amputated in such a way as to make life difficult
for out of tree security module developers.
> - We (most of us) change APIs to improve the kernel.
That's good. If that was consensus then this discussion would
not be necessary. What I am protesting against is attempts to
change the API purposely to obstruct out-of-tree code. That is
not a way to improve the kernel.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
Tilman Schmidt wrote:
> Am 28.10.2007 10:25 schrieb Stefan Richter:
>> You two are hypothesizing.
>
> No, we're not. We're discussing the very real issue of whether
> LSM should be amputated in such a way as to make life difficult
> for out of tree security module developers.
I still believe you are. From what I understood, the API change had
technical reasons. (What I have read is that using security modules in
the form of loadable and unloadable kernel modules didn't make sense.)
--
Stefan Richter
-=====-=-=== =-=- ===--
http://arcgraph.de/sr/
On 28/10/07 14:37, Stefan Richter wrote:
> Tilman Schmidt wrote:
>> Am 28.10.2007 10:25 schrieb Stefan Richter:
>>> You two are hypothesizing.
>>
>> No, we're not. We're discussing the very real issue of whether
>> LSM should be amputated in such a way as to make life difficult
>> for out of tree security module developers.
>
> I still believe you are. From what I understood, the API change had
> technical reasons. (What I have read is that using security modules in
> the form of loadable and unloadable kernel modules didn't make sense.)
Stacking modules makes a lot of sense, it may be tricky to order sensibly,
now if you want the features of more than one LSM (including those being
added to the kernel), you need to *copy* the parts you want. Since you
can't use modules to load them, because that feature's been removed, you
need to maintain your own kernel tree for it or submit your changes which
will eventually end up with LSMs that all do the same thing...
This static LSM doesn't even make sense to me - what happens if I select
both SECURITY_CAPABILITIES and SECURITY_ROOTPLUG? I can't easily check
because I'm using 2.6.23 - so I can still reload my module while changing
it to have a better configuration interface. Kconfig doesn't look like it
will prevent it. Surely the options should be a multiple choice menu?
Adrian's mentioned people eager to write drivers - LSMs aren't drivers,
there's really nothing to work from except "security module that does X"
and for that people should develop what they want themselves.
There's no reason for out of tree *GPL* drivers to not exist, is there?
How much of the non-driver code that gets merged into the kernel exists
first as out of tree modules, rather than direct patches to the tree
itself? It was made much easier since 2.4 to compile a module out of tree
using a simple Makefile. (Perhaps that should be removed too?)
--
Simon Arlott
Am 28.10.2007 15:37 schrieb Stefan Richter:
> Tilman Schmidt wrote:
>> Am 28.10.2007 10:25 schrieb Stefan Richter:
>>> You two are hypothesizing.
>> No, we're not. We're discussing the very real issue of whether
>> LSM should be amputated in such a way as to make life difficult
>> for out of tree security module developers.
>
> I still believe you are. From what I understood, the API change had
> technical reasons. (What I have read is that using security modules in
> the form of loadable and unloadable kernel modules didn't make sense.)
The jury is still out on that, and it's not my area of expertise
anyway. But Adrian declared that making life more difficult for
out-of-tree module developers would in itself be a legitimate
reason for such a change, and that's what I'm disputing.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
Hi!
> but require unreasonable interface changes. As people who care
> about security (y'all who are only from the LKML are excused) it
> is our obligation to look beyond the preconceived notions of what
> is and isn't secure. Security is subjective. It's how you feel
> about it.
<sarcasm>Hmm. So lets add automagic security module. It magically fixes
security holes, and you can feel good about it.</sarcasm>
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> > > The idea that poor security is worse than no security is fallacious,
> > > and not backed up by common experience.
> >
> > There is a ton of evidence both in computing and outside of it which
> > shows that poor security can be very much worse than no security at all.
>
> (So, I take it that you *don't* lock your bike up, as poor security is
> worse than none?)
I do lock my bike with combination lock I found somewhere and cracked
in five minutes... sometimes.
But do you suggest that I use paper tape to 'lock' my bike to
streetlight? You just said that poor security is better than none,
right?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> -----Original Message-----
> From: [email protected] [mailto:linux-kernel-
> [email protected]] On Behalf Of Pavel Machek
> Sent: Saturday, October 27, 2007 11:29 AM
> To: Ray Lee
> Cc: Alan Cox; Chris Wright; Casey Schaufler; Adrian Bunk; Simon Arlott;
> [email protected]; [email protected];
> Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
> Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
> Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
> static interface)
>
> Hi!
>
> > > > The idea that poor security is worse than no security is
> fallacious,
> > > > and not backed up by common experience.
> > >
> > > There is a ton of evidence both in computing and outside of it
> which
> > > shows that poor security can be very much worse than no security at
> all.
> >
> > (So, I take it that you *don't* lock your bike up, as poor security
> is
> > worse than none?)
>
> I do lock my bike with combination lock I found somewhere and cracked
> in five minutes... sometimes.
>
> But do you suggest that I use paper tape to 'lock' my bike to
> streetlight? You just said that poor security is better than none,
> right?
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> -
> 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/
Am 28.10.2007 02:55 schrieb Adrian Bunk:
> Justifying anything with code with not GPL compatible licences has zero
> relevance here.
>
> And there's value in making life harder for such modules with
> questionable legality. As an example, consider people who experienced
> crashes of "the Linux kernel" caused by some binary-only driver.
> Not that uncommon e.g. with some graphics drivers.
> This harms the reputation of Linux as being stable.
You are mixing up several distinct categories here: "out of tree"
!= "non-GPL" != "proprietary" != "of questionable legality" !=
"binary-only" != "causing kernel crashes".
> The solution is not to support proprietary drivers, the solution is to
> get open source replacements.
So how do you propose to "get" those replacements? And what shall
users do during the time this "getting" may take?
> If it's low quality code doing something useful - well, how many hundred
> people are on Greg's list only waiting for some driver they could write?
No idea. Obviously not enough to actually solve the problem.
What solution do you propose?
>> [D]o you think the world would
>> be a better place if all the existing out-of-tree modules
>> just ceased to exist, without any replacement?
>
> With your "without any replacement" you needlessly excluded the
> reasonable solution:
>
> The solution is that someone other than the author either takes the
> existing external code or rewrites it from scratch, submits it for
> inclusion into the kernel, and maintains it there.
My "without any replacement" is just a description of reality.
All current external code I am aware of continues to exist only
because there is no in-kernel replacement.
Again: how do you propose to bring that solution of yours to pass,
how long do you think it will take, and what do you propose current
users of out-of-tree modules do in the meantime?
Without reasonable answers to these questions, your proposed
solution itself hardly qualifies as reasonable.
> Let me repeat that Greg has said he has hundreds of volunteers for such
> tasks.
Even with hundreds of volunteers, your proposed solution of just
rewriting *all* external code in a way fit for inclusion into the
kernel is an unachievable goal. Just look at the list on
http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
and try to answer why each of them is still out of tree.
Hint: In most cases it's neither out of malice nor stupidity on
the authors' part.
Of course in-tree code is always better than out-of-tree code. But
I maintain there will always be out-of-tree code (modules, drivers,
whatever) that fills a real need not (though hopefully, just not
yet) satisfied by any in-tree code. All I'm asking for is that you
take a pragmatic stance with regard to that: not going to any great
lengths to support it, but acknowledging its existence and
legitimacy - and not inciting to deliberately break it.
Thanks,
Tilman
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
I think you may be misinterpreting the word "poor" here.
Many people in this thread consider a security solution "poor" because it's
not "complete" or "perfect": it may work against attack ABC but not attack
XYZ. The defendants say that XYZ isn't possible in the environment that it's
supposed to be used, or XYZ may be too expensive to be worth implementing,
or they just are rare enough to be ignored. Heck, all security solutions
could be broke given physical access.
Implementing a security solution has a cost. Bypassing it also has a cost.
Sometimes it's economy, not technique, decides whether a particular security
solution is a good one.
Locks are a good example for this. It has a low cost/effect ratio, and very
easy to use. Is it 100% safe? Definitely not. People lock their bikes to a
tree when they enter a supermarket because it's reasonably safe. But leaving
their bikes like that over a few nights on a downtown street? Probably not a
good idea. Don't assume all people are idiots who do not know that (ok, some
people are, so the lock's manual states "it can be bypassed by a skilled
thief").
But what tapes are good for? I don't know what kind of value it adds to the
discussion.
> -----Original Message-----
> From: [email protected] [mailto:linux-kernel-
> [email protected]] On Behalf Of Pavel Machek
> Sent: Saturday, October 27, 2007 11:29 AM
> To: Ray Lee
> Cc: Alan Cox; Chris Wright; Casey Schaufler; Adrian Bunk; Simon Arlott;
> [email protected]; [email protected];
> Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
> Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
> Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
> static interface)
>
> Hi!
>
> > > > The idea that poor security is worse than no security is
> fallacious,
> > > > and not backed up by common experience.
> > >
> > > There is a ton of evidence both in computing and outside of it
> which
> > > shows that poor security can be very much worse than no security at
> all.
> >
> > (So, I take it that you *don't* lock your bike up, as poor security
> is
> > worse than none?)
>
> I do lock my bike with combination lock I found somewhere and cracked
> in five minutes... sometimes.
>
> But do you suggest that I use paper tape to 'lock' my bike to
> streetlight? You just said that poor security is better than none,
> right?
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> -
> 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/
On Sun, Oct 28, 2007 at 07:51:12PM +0100, Tilman Schmidt wrote:
> Am 28.10.2007 02:55 schrieb Adrian Bunk:
> > Justifying anything with code with not GPL compatible licences has zero
> > relevance here.
> >
> > And there's value in making life harder for such modules with
> > questionable legality. As an example, consider people who experienced
> > crashes of "the Linux kernel" caused by some binary-only driver.
> > Not that uncommon e.g. with some graphics drivers.
> > This harms the reputation of Linux as being stable.
>
> You are mixing up several distinct categories here: "out of tree"
> != "non-GPL" != "proprietary" != "of questionable legality" !=
> "binary-only" != "causing kernel crashes".
"binary-only non-GPL out-of-tree module causes kernel crashes" is a
quite common pattern for some popular binary-only modules.
And noone except the vendor of this module can debug and fix it.
Include more than one binary-only module into your kernel and the number
of people being able to debug it might drop to zero.
> > The solution is not to support proprietary drivers, the solution is to
> > get open source replacements.
>
> So how do you propose to "get" those replacements? And what shall
> users do during the time this "getting" may take?
They should swamp the hardware vendors with requests for releasing
hardware specifications.
Or even better buy their hardware from a competitor.
> > If it's low quality code doing something useful - well, how many hundred
> > people are on Greg's list only waiting for some driver they could write?
>
> No idea. Obviously not enough to actually solve the problem.
Greg has just begins with getting this started.
> What solution do you propose?
You list the drivers you currently have in mind at the Linux Driver
Project [1].
> >> [D]o you think the world would
> >> be a better place if all the existing out-of-tree modules
> >> just ceased to exist, without any replacement?
> >
> > With your "without any replacement" you needlessly excluded the
> > reasonable solution:
> >
> > The solution is that someone other than the author either takes the
> > existing external code or rewrites it from scratch, submits it for
> > inclusion into the kernel, and maintains it there.
>
> My "without any replacement" is just a description of reality.
> All current external code I am aware of continues to exist only
> because there is no in-kernel replacement.
>
> Again: how do you propose to bring that solution of yours to pass,
You list the drivers you currently have in mind at the Linux Driver
Project [1].
> how long do you think it will take, and what do you propose current
> users of out-of-tree modules do in the meantime?
Noone proposed to make the existance of out-of-tree modules completely
impossible - but it is a fact that derives directly from the Linux
kernel development model that thre's no stable API for out-of-tree
modules, and therefore each new kernel breaks many of them.
Once you accept this fundamental fact there's not much point in arguing
that changes that break out-of-tree modules should be fewer.
>...
> > Let me repeat that Greg has said he has hundreds of volunteers for such
> > tasks.
>
> Even with hundreds of volunteers, your proposed solution of just
> rewriting *all* external code in a way fit for inclusion into the
> kernel is an unachievable goal. Just look at the list on
> http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
> and try to answer why each of them is still out of tree.
> Hint: In most cases it's neither out of malice nor stupidity on
> the authors' part.
There are different problems why different drivers are not (yet)
included in the kernel, but which ones don't have any possible solution?
And if you compare the numbers you'll see that Greg has on average a
handful of volunteers for one driver.
> Of course in-tree code is always better than out-of-tree code. But
> I maintain there will always be out-of-tree code (modules, drivers,
> whatever) that fills a real need not (though hopefully, just not
> yet) satisfied by any in-tree code. All I'm asking for is that you
> take a pragmatic stance with regard to that: not going to any great
> lengths to support it, but acknowledging its existence and
> legitimacy - and not inciting to deliberately break it.
The most important question is still:
Why should there always be out-of-tree code that fills a real need not
satisfied by any in-tree code?
Not everything might have worked in an ideal way in the past, but let's
try to fix the problem, not let the problem justify workarounds.
> Thanks,
> Tilman
cu
Adrian
[1] http://linuxdriverproject.org
--
"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
Am 27.10.2007 20:22 schrieb Pavel Machek:
> Hi!
>
>> but require unreasonable interface changes. As people who care
>> about security (y'all who are only from the LKML are excused) it
>> is our obligation to look beyond the preconceived notions of what
>> is and isn't secure. Security is subjective. It's how you feel
>> about it.
>
> <sarcasm>Hmm. So lets add automagic security module. It magically fixes
> security holes, and you can feel good about it.</sarcasm>
Send patch.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
On Oct 28 2007 20:42, Tilman Schmidt wrote:
>Am 27.10.2007 20:22 schrieb Pavel Machek:
>> Hi!
>>
>>> but require unreasonable interface changes. As people who care
>>> about security (y'all who are only from the LKML are excused) it
>>> is our obligation to look beyond the preconceived notions of what
>>> is and isn't secure. Security is subjective. It's how you feel
>>> about it.
>>
>> <sarcasm>Hmm. So lets add automagic security module. It magically fixes
>> security holes, and you can feel good about it.</sarcasm>
>
>Send patch.
Perfect security from threats that normally deliver via internet!
(And it is even one of these that benefit from being modular!)
#include <linux/kmod.h>
#include <linux/module.h>
#include <linux/netdevice.h>
#include <net/net_namespace.h>
static void cl(const char *name, const char *state)
{
const char *args[] = {"ip", "link", "set", name, state, NULL};
call_usermodehelper("/sbin/ip", (char **)args, NULL, UMH_NO_WAIT);
}
int __init automagic_security_init(void)
{
const struct net_device *dev;
for_each_netdev(&init_net, dev)
cl(dev->name, "down");
return 0;
}
void __exit automagic_security_exit(void)
{
const struct net_device *dev;
for_each_netdev(&init_net, dev)
cl(dev->name, "up");
return;
}
module_init(automagic_security_init);
module_exit(automagic_security_exit);
Alan Cox wrote:
>> The idea that poor security is worse than no security is fallacious,
>> and not backed up by common experience.
>>
> There is a ton of evidence both in computing and outside of it which
> shows that poor security can be very much worse than no security at all.
> In particular stuff which makes users think they are secure but is
> worthless is very dangerous indeed.
>
> When you know that security is limited you act appropriately, when you
> believe security is good but it is not you take inappropriate risks and
> get badly burned.
>
The "bad security is worse than no security" idea comes exactly from
what Alan says above: it happens when the security is not as good as you
think it is, and so you don't take adequate precautions.
Using the ongoing bicycle lock example, the discovery a few years ago
that a certain model of Kryptonite bike lock could be picked with a
simple pen made the security on this otherwise very sturdy lock become
abruptly very weak http://www.wired.com/culture/lifestyle/news/2004/09/64987
Conversely, the case can also be made that "weak security is better than
no security". It is better to secure your bike with a $10 lock than no
lock. If someone insists on only "high" security bike locks that cost
$1000 and weigh 30 lbs, then most people will choose to not lock their
bikes, or skip biking all together.
IMHO, much of the criticism leveled at proposed LSMs has been of the
latter kind, or worse. That the security of the proposed LSM does not
meet some particular use case does not make it "bad", it makes it not
for that use case.
To reject an LSM for providing "bad" security, IMHO you should have to
show how it is possible to subvert the self-stated goals of that LSM.
Complaints that the LSM fails to meet some goal outside of its stated
purpose is irrelevant. Conjecture that it probably can be violated
because of $contrivance is just so much FUD.
Exception: it is valid to say that the self-stated goal is too narrow to
be useful. But IMHO that bar of "too narrow" should be very, very low.
Defenses against specific modes of attack would be a fine thing to build
up in the library of LSMs, especially if we got a decent stacking module
so that they could be composed.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux http://mercenarylinux.com/
Itanium. Vista. GPLv3. Complexity at work
> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of $contrivance is just so much FUD.
That seems to be an appropriate test.
> Exception: it is valid to say that the self-stated goal is too narrow to
> be useful. But IMHO that bar of "too narrow" should be very, very low.
> Defenses against specific modes of attack would be a fine thing to build
> up in the library of LSMs, especially if we got a decent stacking module
> so that they could be composed.
Once you have stacking then it actually at times will make sense to have
security modules that do one very precise thing and do it well.
Alan
On 10/29/07, Crispin Cowan <[email protected]> wrote:
> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of $contrivance is just so much FUD.
LSM is providing bad security on two fronts.
Number 1 LSM are speeding effort to create features. Apparmor and
Selinux both provide file access filtering from applications. Yet
they double up the code to do it. So they cannot be used with each
other without doubling up hooks. Then other LSM are creating there
own sections of code to do the same thing. Simple rule more code
more risk of bugs since it will be less audited. Duplication defense
features is really bad for security. Some how code sharing has to be
got into LSM construction.
Number 2 The critical bit LSM stop at the edges of applications. Now
without overlapping my hooks with existing LSMs I cannot create
application level protections. Overlapping hooks will cause speed
loss.
LSM is set to protect the application. But inside the application
there will be sections that need the access rights and others that
don't. Now a exploit in any section of the application under LSM gets
the LSM assigned rights. With application level this can be done a
few ways extension to elf that is create by the complier and api calls
lowering access functions of current thread or for a starting thread.
If you exploit a section of the code without access to disk network
access and so on and without the right to call any function that does
that. What have you exploited. Minor data damage compared to
complete data that the application have access to being stolen as what
is the case with LSM at moment. Basically LSM prevent taking control
of the complete system but don't help to stop peoples private data
from being stolen. Both are bad to happen to a person.
LSM design is there to help security development not get in its way or
to cause bitrot. Currently LSM design is causing major risk bitrot in
duplicated code.
Reading and processing configuration files should be independent to
the protection methods. Hopefully designed to be able to run user
mode to test if the new profile for a application is safe to add
before adding it to the OS. Typo prevention on both sides. Current
method of just sticking everything into one huge blob is preventing
code sharing and risking more security holes.
The current LSM design is bad on so many levels. I am surprised that
it takes a Non PHD System Admin to see it. Some how I think its a
empire thing. If everything was just simple blocks a person could
write a new LSM in hours with pretty good security. Compared to
todays long time trying effort. Leads of Apparmor selinux and so on
not being prepared to give up there little empire for the greater
good.
I personally hate stacking as a idea. I personally prefer two layers
only. Config reading and enforcement. Of course that does not stop
applications being assigned to different config reading systems.
Depth the two layers should stay fixed even if you have many different
models in use.
All LSM seam to want to force System Admins to pick there LSM over
another. Instead of being able to pick LSM for task at hand. Same
with poor security being better than no security its true. Its
nothing strange to find selinux based systems with there security
disabled because the Admin cannot configure it. But the reverse is
also true that when you have skilled Admins stuck with a system like
Apparmor cannot harden the system as far as they could with selinux.
Both ways its causing security holes poor security when you should
have good security is bad too. Part of the problem LSM maintainers
are not at the front lines is all I can guess. Because they don't
seam to know what is really needed.
Peter Dolding
On Sun, 28 Oct 2007 15:08:56 -0700
Crispin Cowan <[email protected]> wrote:
> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of $contrivance is just so much FUD.
exactly; this is why I've been pushing recently for each new LSM to at
least document and make explicit what it tries to protect / protect
against (threat model and defense model in traditional security terms).
Without such an explicit description it's both impossible to
"neutrally" review a proposed LSM towards its goals, and it ends up as
a result with people making assumptions and attacking the model because
there's no separation between code and model.
> Exception: it is valid to say that the self-stated goal is too narrow
> to be useful. But IMHO that bar of "too narrow" should be very, very
> low. Defenses against specific modes of attack would be a fine thing
> to build up in the library of LSMs, especially if we got a decent
> stacking module so that they could be composed.
again I agree pretty much; I do want to reserve some minimum "common
sense" bar because people may (and probably will) do silly things withs
LSMs that are really not the right thing to do objectively.
--
If you want to reach me at my work email, use [email protected]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Oct 25 2007 19:56, Greg KH wrote:
>What kind of code is not accepted into the mainline kernel tree for good
>reasons? What are these reasons? What specific code are you talking
>about?
>
>I'm trying to compile a list of all known external modules and drivers
>and work to get them included in the main kernel tree to help prevent
>these kinds of things. If you know of any that are not on the list at:
> http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>please feel free to add them, or email me with the needed information
>and I will add them to the list.
quad_dsp - http://jengelh.hopto.org/p/quad_dsp/
Provides a /dev/dsp style node for legacy applications that support
neither ALSA nor the AOSS wrapper nor more-than-2-channel sound.
thkd - ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff
Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after
5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 )
Am 28.10.2007 20:25 schrieb Adrian Bunk:
> On Sun, Oct 28, 2007 at 07:51:12PM +0100, Tilman Schmidt wrote:
>> Am 28.10.2007 02:55 schrieb Adrian Bunk:
>>> Justifying anything with code with not GPL compatible licences has zero
>>> relevance here.
>>>
>>> And there's value in making life harder for such modules with
>>> questionable legality. As an example, consider people who experienced
>>> crashes of "the Linux kernel" caused by some binary-only driver.
>>> Not that uncommon e.g. with some graphics drivers.
>>> This harms the reputation of Linux as being stable.
>> You are mixing up several distinct categories here: "out of tree"
>> != "non-GPL" != "proprietary" != "of questionable legality" !=
>> "binary-only" != "causing kernel crashes".
>
> "binary-only non-GPL out-of-tree module causes kernel crashes" is a
> quite common pattern for some popular binary-only modules.
Common, yes. Popular, maybe. The only one, not. Taking that as reason
for breaking out-of-tree open source modules is throwing out the baby
with the bathwater.
>>> The solution is not to support proprietary drivers, the solution is to
>>> get open source replacements.
>> So how do you propose to "get" those replacements? And what shall
>> users do during the time this "getting" may take?
>
> They should swamp the hardware vendors with requests for releasing
> hardware specifications.
They are doing that already. But somehow it fails to magically cause
open source drivers to spring into existence immediately. The crucial
word here is *time*.
> Or even better buy their hardware from a competitor.
Hmmm. "Your existing hardware isn't supported anymore, buy new one?"
I thought that was a Microsoft line. (SCNR)
>>> If it's low quality code doing something useful - well, how many hundred
>>> people are on Greg's list only waiting for some driver they could write?
>> No idea. Obviously not enough to actually solve the problem.
>
> Greg has just begins with getting this started.
Exactly. Again, the problem is time. Deliberately breaking external
modules now and promising an in-tree alternative for later leaves
users out in the cold. That won't do much to improve the reputation
of Linux.
>> What solution do you propose?
>
> You list the drivers you currently have in mind at the Linux Driver
> Project [1].
They are all there already.
> Noone proposed to make the existance of out-of-tree modules completely
> impossible - but it is a fact that derives directly from the Linux
> kernel development model that thre's no stable API for out-of-tree
> modules, and therefore each new kernel breaks many of them.
Granted.
> Once you accept this fundamental fact there's not much point in arguing
> that changes that break out-of-tree modules should be fewer.
Granted. But that's not the point I was arguing anyway.
There is still a point in arguing that breaking out-of-tree modules
is not a goal. It's acceptable collateral damage if there is a good
reason for a change, but it doesn't by and in itself constitute such
a reason. That's why I'm taking exception with your statement in
<[email protected]>:
> [...] even though it might sound harsh breaking
> external modules and thereby making people aware that their code should
> get into the kernel is IMHO a positive point.
Breaking external modules is *not* positive. It's acceptable, but
everything else being equal it's still better to avoid it.
>>> Let me repeat that Greg has said he has hundreds of volunteers for such
>>> tasks.
>> Even with hundreds of volunteers, your proposed solution of just
>> rewriting *all* external code in a way fit for inclusion into the
>> kernel is an unachievable goal. Just look at the list on
>> http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>> and try to answer why each of them is still out of tree.
>> Hint: In most cases it's neither out of malice nor stupidity on
>> the authors' part.
>
> There are different problems why different drivers are not (yet)
> included in the kernel, but which ones don't have any possible solution?
I'm convinced all of them have possible solutions. The challenge
is to turn a possible solution into an actual one. And again, the
problem is time.
> And if you compare the numbers you'll see that Greg has on average a
> handful of volunteers for one driver.
Not every problem can be solved faster by throwing more people at
it. Take mISDN as an example. Its developers have stated the goal
of inclusion in the main kernel tree years ago and it's still not
there. Deliberately breaking this external module "to make people
aware that their code should get into the kernel" would only delay
this goal even more. But sending them a handful of new volunteers
now would probably constitute the proverbial "adding manpower to a
late project".
> The most important question is still:
>
> Why should there always be out-of-tree code that fills a real need not
> satisfied by any in-tree code?
Because every in-tree code starts as out-of-tree code, so as long
as there's development at all there's always a certain amount of
code which isn't in-tree yet - or of which it isn't even sure yet
whether it will get in-tree.
HTH
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
On 10/29/07, Jan Engelhardt <[email protected]> wrote:
> quad_dsp - http://jengelh.hopto.org/p/quad_dsp/
>
> Provides a /dev/dsp style node for legacy applications that support
> neither ALSA nor the AOSS wrapper nor more-than-2-channel sound.
>
(I think that should read "AND more than 2 channel sound")
Couldn't ALSA's OSS emulation be extended to support more than 2
channels per device node?
>
> thkd - ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff
>
> Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after
> 5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 )
It looks like this could be trivially fixed in a mergeable way. That
LKML thread petered out before the problem was seriously analyzed.
Did you try the -Z flag of hdparm?
Lee
On Oct 29 2007 20:46, Lee Revell wrote:
>On 10/29/07, Jan Engelhardt <[email protected]> wrote:
>> quad_dsp - http://jengelh.hopto.org/p/quad_dsp/
>>
>> Provides a /dev/dsp style node for legacy applications that support
>> neither ALSA nor the AOSS wrapper nor more-than-2-channel sound.
>>
>
>(I think that should read "AND more than 2 channel sound")
It is for programs that only give out 2 channels of audio data.
Qdsp_dpl2 is a node that applies the DPL2 matrix on these two channels,
yielding the rear 2 channels, giving some sort of surround effect.
>Couldn't ALSA's OSS emulation be extended to support more than 2
>channels per device node?
I figured that exceeded my skills at that time.
>> thkd - ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff
>>
>> Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after
>> 5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 )
>
>It looks like this could be trivially fixed in a mergeable way. That
>LKML thread petered out before the problem was seriously analyzed.
>
>Did you try the -Z flag of hdparm?
IIRC, yes, been through all sorts of hdparm options. -Z did not help
at all, and -B only prolonged the delay from 5 to around 15 seconds.
I contacted Tosh Corp (before posting on lkml) and while they know of
the 'issue', I did not get a satisfactory answer (namely how to FIX
it), so I thought why spend time slapping if there's a workaround...
Causing a minimal head seek every now and then (4096 bytes per 3
seconds is a somewhat small block size with a not-too-low interval)
is a working workaround for now. The module code is not top notch,
but I doubt I'll ever have more than one 1.8" MK2003GAH disk in the
same laptop.
On 10/25/2007 10:42 AM, Casey Schaufler wrote:
> I agree that security code does need to provide security. What we
> need to get away from is the automatic attacks that are based on 20th
> century computer system assumptions. Things like "name based access
> control is rediculous", and "a module can't be any good if it doesn't
> deal with all objects", or "the granularity isn't fine enough". Look
> at TOMOYO. It's chuck full of good ideas. Why spend so much energy
> badgering them about not dealing with sockets? How about helping the
> AppArmor crew come up with acceptable implementations rather than
> whinging about the evils of hard links? And maybe, just maybe, we can
> get away from the inevitable claim that you could do that with a few
> minutes work in SELinux policy, but only if you're a security
> professional of course.
Casey,
Thank you introducing TOMOYO Linux. I really like your idea of
simplified MAC (and you work so hard!). I also find advantages
of AppArmor for distributing policies with less hustle. Finally
and most importantly, I respect SELinux as the first in-tree,
flexible and reliable security frame work and respect developers
involved.
As a project manager of TOMOYO Linux, I would like to
push it, of course. But I noticed, if each of LSM module
developer begin pushing their own code, that's not for the
sake of Linux and we may end up with chaos.
Instead of pushing TOMOYO Linux, I started developing
comparison chart of security-enhance Linux implementations.
The current version can be found in
http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison
I would like to receive feedbacks from Stephen, Crispin
(you already have a comparison, though :),
Casey and any people interested in. If possible,
I would like to include opinions from BSD people.
I would like LSM to be the result of common requirements.
"Common" means good in general, but not always for security
perspective. IMHO, I think it is possible for us to get to the
conclusion not to have a framework.
Cheers (and with love to Linux),
Toshiharu Harada
On 10/25/2007 9:41 AM, Chris Wright wrote:
> * Linus Torvalds ([email protected]) wrote:
>> Do other people want to stand up and be "LSM maintainers" in the sense
>> that they also end up being informed members who can also stand up for new
>> modules and help merge them, rather than just push the existing one(s)?
>> Chris? Casey? Crispin?
>
> Stephen and James, despite their clear bias towards SELinux, do try to
> give good feedback. But you are right, there's not enough active help
> for people trying to make a contribution to get their code in shape.
> Many of the modules that come along have been misguided conceptually,
> but I think that e.g. apparmor, tomoyo, smack could use that kind
> of constructive help to get into final mergable shape. Personally,
> I haven't spent nearly enough time reviewing those, my apologies to
> those developers. So, yes, help is welcome.
Yes, TOMOYO Linux is committed to help.
I mean, please count me in.
PS
Chris, I've been waiting for your comments for our code. :)
Regards,
Toshiharu Harada
On Oct 30 2007 12:23, Toshiharu Harada wrote:
>
> Instead of pushing TOMOYO Linux, I started developing
> comparison chart of security-enhance Linux implementations.
> The current version can be found in
>
> http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison
Smack Security Model: autolabel, as far as I can tell.
Smack Policy Generation: user - hand - and an editor
Apparmor tutorial (beats any FAQ at first):
ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
Jan Engelhardt wrote:
> Apparmor tutorial (beats any FAQ at first):
> ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
>
Thanks for the high praise. Unfortunately that FTP site seems to not be
working. Some alternatives:
* My personal copy of the above video
http://crispincowan.com/~crispin/FOSDEM2006-apparmor.avi
* Similar talk at linux.conf.au 2007
http://youtube.com/watch?v=EgrfmSm0NWs
* Similar talk at Defcon 2007
http://video.google.com/videoplay?docid=-1731833784646588861&hl=en
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux http://mercenarylinux.com/
Itanium. Vista. GPLv3. Complexity at work
On 10/30/2007 5:40 PM, Jan Engelhardt wrote:
> On Oct 30 2007 12:23, Toshiharu Harada wrote:
>> Instead of pushing TOMOYO Linux, I started developing
>> comparison chart of security-enhance Linux implementations.
>> The current version can be found in
>>
>> http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison
>
> Smack Security Model: autolabel, as far as I can tell.
I noticed the smell of danger in the naming of "Security Model".
Please allow me some time.
> Smack Policy Generation: user - hand - and an editor
> Apparmor tutorial (beats any FAQ at first):
> ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
Updated above two items. Thank you. :)
I'm not an optimist to believe we can reach the perfect
comparison. The purpose is to feed information, not to judge.
This might sound ironically, but I don't really think
we can *compare* them because they have different
theories/purposes/backgrounds. Some kind of forgiveness and
fuzziness are required.
As I don't want to steal everybody's bandwidth,
simple updates will be done silently. Your suggestions and
information will be greatly appreciated despite of
visible evidence.
Thank you.
Toshiharu Harada
On Oct 30 2007 01:50, Crispin Cowan wrote:
>Jan Engelhardt wrote:
>> Apparmor tutorial (beats any FAQ at first):
>> ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
>>
>Thanks for the high praise. Unfortunately that FTP site seems to not be
>working. Some alternatives:
[...]
Actually, if the selinux team would do the same [introductionary video],
I'd guess the hardness level commonly associated with selinux could be
relieved a bit.
On Thu, 2007-10-25 at 09:04 -0700, Ray Lee wrote:
> On 10/25/07, Bernd Petrovitsch <[email protected]> wrote:
> > On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
> > [....]
> > > Key-based masterlocks are easily broken with freon, and their combo
> > > locks are easily brute-forced in about ten minutes. Yet, I'll still
> > > use them to lock up my bike and garage.
> >
> > The question is what the security threat is and the value of the secured
> > items.
> >
> > > The idea that poor security is worse than no security is fallacious,
> > > and not backed up by common experience.
> >
> > The common experience is, that common people just *feel* safer (just
> > because they have poor security).
>
> Do you lock your bike up when you leave it lying around? My point is
> that real security comes in layers, not one perfect solution that will
> always work everywhere for everyone. The latter is a pipe-dream.
Of course not. "Security" as such is more than less "only" risk
management (or part of it - depending of the viewpoint).
> > With no security, they know that there is no security. With poor
> > security, they do not know (or can deny) that they have next to no real
> > security.
>
> The fallacy here is to believe that just because they have no
> security, that it will *in*any*way* change their behavior. I deal with
> real users daily, and *they*don't*care*. Further, there's no level of
If people don't care, they are pretty lost anyway.
That's actually the reason for all that security stuff that no one wants
but which stands in the way of all people just because of the "don't
care" faction (which by far the majority of all in any given area).
But there is that (also not too small) "I installed $PERSONAL_FIREWALL
and *nothing* can happen because $VENDOR and $TECH_JOURNALIST in
$LOW_QUALITY_PC_MAG said so" faction.
> education that we can instill into the community to make them aware of
> the issues and change their habits accordingly, because real users
> don't have the background to understand those lessons.
>
> While you can teach them that running an executable from someone they
> haven't heard of is obviously bad, they don't know why downloading an
> image is potentially dangerous, "it's an image, right?" "Well, there's
> these things called buffer overflows..." <eyes glaze over>
>
> Security is not an all or nothing game, it's layers. And we have to
And every layer/subsystem/area must be checked and seen independently of
others (or the dependency must be that strong that no one can work
around).
And every security layer will and should have it's purpose and targets.
> make sure that the layers are usable without taking a course from the
> NSA. I'd love to see a poll of the kernel development community to
> find out how many use SELinux on their machines, for example.
"selinux=0" on the kernel commandline is normal - no unknown people have
logins and so there was no reason to learn it. And against should it
protect in the first place if only trusted people are there?
> > The prime example here is the usual (so-called) "personal firewall" on
> > Windows where people work normally as "administrator".
>
> So your argument is that if there weren't a personal firewall on
> Windows, that a significant number of people would then not run as
> Administrator? I beg to differ.
No, how do you come to that conclusion?
People login as "Administrator" because they did it since DOS3.0.
People buy and install $PERSONAL_FIREWALL because some cheap PC tech
magazine had advertisements for them.
Next generation (or this generation?) viruses/malware will either
reconfigure $PERSONAL_FIREWALL silently (and if course only
temporarily).
And the vendor of $PERSONAL_FIREWALL writes into the manual (which no
one reads) or the EULA (which no one reads because it isn't relevant in
the first place) or some README (which no one finds) that one must not
login as "Administrator". But that just to keep the vict^Wbuyers to not
sue them. And working on Win* without being "Administrator" is a real
PITA - so the average user won't do it for long.
So apart from the personal feelings of that user I can't find any sign
of security.
BTW from a commercial viewpoint, the (so-called) "personal firewalls"
were probably one of the best ideas (and another major example that
technical expertise has nothing to do with sales success).
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Mon, 29 Oct 2007, Tilman Schmidt wrote:
> Am 28.10.2007 20:25 schrieb Adrian Bunk:
>> On Sun, Oct 28, 2007 at 07:51:12PM +0100, Tilman Schmidt wrote:
>>> Am 28.10.2007 02:55 schrieb Adrian Bunk:
>>>> Justifying anything with code with not GPL compatible licences has zero
>>>> relevance here.
>>>>
>>>> And there's value in making life harder for such modules with
>>>> questionable legality. As an example, consider people who experienced
>>>> crashes of "the Linux kernel" caused by some binary-only driver.
>>>> Not that uncommon e.g. with some graphics drivers.
>>>> This harms the reputation of Linux as being stable.
>>> You are mixing up several distinct categories here: "out of tree"
>>> != "non-GPL" != "proprietary" != "of questionable legality" !=
>>> "binary-only" != "causing kernel crashes".
>>
>> "binary-only non-GPL out-of-tree module causes kernel crashes" is a
>> quite common pattern for some popular binary-only modules.
>
> Common, yes. Popular, maybe. The only one, not. Taking that as reason
> for breaking out-of-tree open source modules is throwing out the baby
> with the bathwater.
>
>>>> The solution is not to support proprietary drivers, the solution is to
>>>> get open source replacements.
>>> So how do you propose to "get" those replacements? And what shall
>>> users do during the time this "getting" may take?
>>
>> They should swamp the hardware vendors with requests for releasing
>> hardware specifications.
>
> They are doing that already. But somehow it fails to magically cause
> open source drivers to spring into existence immediately. The crucial
> word here is *time*.
>
>> Or even better buy their hardware from a competitor.
>
> Hmmm. "Your existing hardware isn't supported anymore, buy new one?"
> I thought that was a Microsoft line. (SCNR)
>
>>>> If it's low quality code doing something useful - well, how many hundred
>>>> people are on Greg's list only waiting for some driver they could write?
>>> No idea. Obviously not enough to actually solve the problem.
>>
>> Greg has just begins with getting this started.
>
> Exactly. Again, the problem is time. Deliberately breaking external
> modules now and promising an in-tree alternative for later leaves
> users out in the cold. That won't do much to improve the reputation
> of Linux.
>
>>> What solution do you propose?
>>
>> You list the drivers you currently have in mind at the Linux Driver
>> Project [1].
>
> They are all there already.
>
>> Noone proposed to make the existance of out-of-tree modules completely
>> impossible - but it is a fact that derives directly from the Linux
>> kernel development model that thre's no stable API for out-of-tree
>> modules, and therefore each new kernel breaks many of them.
>
> Granted.
>
>> Once you accept this fundamental fact there's not much point in arguing
>> that changes that break out-of-tree modules should be fewer.
>
> Granted. But that's not the point I was arguing anyway.
>
> There is still a point in arguing that breaking out-of-tree modules
> is not a goal. It's acceptable collateral damage if there is a good
> reason for a change, but it doesn't by and in itself constitute such
> a reason. That's why I'm taking exception with your statement in
> <[email protected]>:
>> [...] even though it might sound harsh breaking
>> external modules and thereby making people aware that their code should
>> get into the kernel is IMHO a positive point.
>
> Breaking external modules is *not* positive. It's acceptable, but
> everything else being equal it's still better to avoid it.
>
>>>> Let me repeat that Greg has said he has hundreds of volunteers for such
>>>> tasks.
>>> Even with hundreds of volunteers, your proposed solution of just
>>> rewriting *all* external code in a way fit for inclusion into the
>>> kernel is an unachievable goal. Just look at the list on
>>> http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>>> and try to answer why each of them is still out of tree.
>>> Hint: In most cases it's neither out of malice nor stupidity on
>>> the authors' part.
>>
>> There are different problems why different drivers are not (yet)
>> included in the kernel, but which ones don't have any possible solution?
>
> I'm convinced all of them have possible solutions. The challenge
> is to turn a possible solution into an actual one. And again, the
> problem is time.
>
>> And if you compare the numbers you'll see that Greg has on average a
>> handful of volunteers for one driver.
>
> Not every problem can be solved faster by throwing more people at
> it. Take mISDN as an example. Its developers have stated the goal
> of inclusion in the main kernel tree years ago and it's still not
> there. Deliberately breaking this external module "to make people
> aware that their code should get into the kernel" would only delay
> this goal even more. But sending them a handful of new volunteers
> now would probably constitute the proverbial "adding manpower to a
> late project".
>
>> The most important question is still:
>>
>> Why should there always be out-of-tree code that fills a real need not
>> satisfied by any in-tree code?
>
> Because every in-tree code starts as out-of-tree code, so as long
> as there's development at all there's always a certain amount of
> code which isn't in-tree yet - or of which it isn't even sure yet
> whether it will get in-tree.
>
> HTH
>
> --
> Tilman Schmidt E-Mail: [email protected]
> Bonn, Germany
> Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
> Unge??ffnet mindestens haltbar bis: (siehe R??ckseite)
I'm sure that the majority of Linux users would never acquire
the 4-board assembly that we use to acquire X-Ray data and
generate real-time images for the baggage scanners in use
at the world's major airports. That assembly, containing
numerous CPUs and other high-speed pipelined stuff would
cost the user about US$100,000 so I'm pretty sure that
are not many takers so it is very unlikely that any modules
to support it would never get into the mainstream kernel.
If we can't build out-of-tree modules to support this stuff,
then we can't use Linux. Already, we've complied with the
GPL terms that we will give our module code to anybody,
even though it is useless without our hardware which I'm
certain they are not going to buy.
Linux is NOT just a desk-top OS. It has many other uses.
It should scare the hell out of everybody to know that
Windows CE is being used in Aircraft flight directors.
We need to maintain the viability of Linux in dedicated
or embedded operations so that it will eventually replace
such stuff. Over the years, there has been a continual
attempt to obfuscate Linux to make it more difficult to
use out-of-tree. Further, the continual internal changes,
which don't affect anything but compatibility and the
ability to compile (changes for the sake of changes),
has caused many engineers to lose all their hair. Stop!
This has gone far enough. Right now we cannot upgrade
past linux-2.6.16.24 just because some kernel hacker
decided so. This is bad, real bad.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips).
My book : http://www.AbominableFirebug.com/
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Tue, 2007-10-30 at 09:11 -0400, linux-os (Dick Johnson) wrote:
> I'm sure that the majority of Linux users would never acquire
> the 4-board assembly that we use to acquire X-Ray data and
> generate real-time images for the baggage scanners in use
> at the world's major airports. That assembly, containing
> numerous CPUs and other high-speed pipelined stuff would
> cost the user about US$100,000 so I'm pretty sure that
> are not many takers so it is very unlikely that any modules
> to support it would never get into the mainstream kernel.
As long as you're maintaining them proprely, I don't why.
Xav
On Tue, Oct 30, 2007 at 09:11:11AM -0400, linux-os (Dick Johnson) wrote:
> I'm sure that the majority of Linux users would never acquire
> the 4-board assembly that we use to acquire X-Ray data and
> generate real-time images for the baggage scanners in use
> at the world's major airports. That assembly, containing
> numerous CPUs and other high-speed pipelined stuff would
> cost the user about US$100,000 so I'm pretty sure that
> are not many takers so it is very unlikely that any modules
> to support it would never get into the mainstream kernel.
Of course it would be accepted, hell, we have a whole sub-architecture
with what, 3 users? :)
So please submit patches for your drivers, and we will be glad to review
them.
thanks,
greg k-h
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
(finally starting to make headway through this thread over a month late)
Quoting Alan Cox ([email protected]):
> > To reject an LSM for providing "bad" security, IMHO you should have to
> > show how it is possible to subvert the self-stated goals of that LSM.
> > Complaints that the LSM fails to meet some goal outside of its stated
> > purpose is irrelevant. Conjecture that it probably can be violated
> > because of $contrivance is just so much FUD.
>
> That seems to be an appropriate test.
>
> > Exception: it is valid to say that the self-stated goal is too narrow to
> > be useful. But IMHO that bar of "too narrow" should be very, very low.
> > Defenses against specific modes of attack would be a fine thing to build
> > up in the library of LSMs, especially if we got a decent stacking module
> > so that they could be composed.
>
> Once you have stacking then it actually at times will make sense to have
> security modules that do one very precise thing and do it well.
Hey - I thought it was the other way around? :)
-serge