[PATCH RFC] Alternative 64-bit capability patch

[Andrew Morgan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Serge,

Here is a more fully formed 64-bit capabilities patch than the one I
sent you last week. Its still subject to a bunch of testing.

[The patch is against Linus' v2.6.24-rc1 tree.]

Cheers

Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFHJYUfQheEq9QabfIRArD0AJ0adXWTSaOBYWhHfzqUqWzbtilnpACfeLc6
i2yeS9ECRNhZyrFxXc07YME=
=LgZV
-END PGP SIGNATURE-
>From f1e1bab2a71854b4224d3b6f3f3ca187584893e3 Mon Sep 17 00:00:00 2001
From: Andrew Morgan <[EMAIL PROTECTED]>
Date: Sun, 28 Oct 2007 23:36:08 -0700
Subject: [PATCH] This patch adds 64-bit capability support to the kernel.

The patch has supports legacy (32-bit) capability use, and where
possible translates 32-bit capabilities from userspace and the VFS
to kernel space.
---
 fs/nfsd/auth.c |8 +-
 fs/proc/array.c|   18 +++--
 include/linux/capability.h |  191 ++--
 kernel/capability.c|   81 +--
 mm/oom_kill.c  |5 +-
 security/commoncap.c   |   92 +
 security/dummy.c   |   13 ++-
 7 files changed, 284 insertions(+), 124 deletions(-)

diff --git a/fs/nfsd/auth.c b/fs/nfsd/auth.c
index 2192805..3504093 100644
--- a/fs/nfsd/auth.c
+++ b/fs/nfsd/auth.c
@@ -11,8 +11,6 @@
 #include 
 #include 
 
-#define	CAP_NFSD_MASK (CAP_FS_MASK|CAP_TO_MASK(CAP_SYS_RESOURCE))
-
 int nfsexp_flags(struct svc_rqst *rqstp, struct svc_export *exp)
 {
 	struct exp_flavor_info *f;
@@ -69,10 +67,10 @@ int nfsd_setuser(struct svc_rqst *rqstp, struct svc_export *exp)
 	ret = set_current_groups(cred.cr_group_info);
 	put_group_info(cred.cr_group_info);
 	if ((cred.cr_uid)) {
-		cap_t(current->cap_effective) &= ~CAP_NFSD_MASK;
+		cap_drop_nfsd_cap(current->cap_effective);
 	} else {
-		cap_t(current->cap_effective) |= (CAP_NFSD_MASK &
-		  current->cap_permitted);
+		cap_raise_nfsd_cap(current->cap_effective,
+   current->cap_permitted);
 	}
 	return ret;
 }
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 63c95af..eb9c274 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -288,12 +288,18 @@ static inline char *task_sig(struct task_struct *p, char *buffer)
 
 static inline char *task_cap(struct task_struct *p, char *buffer)
 {
-return buffer + sprintf(buffer, "CapInh:\t%016x\n"
-			"CapPrm:\t%016x\n"
-			"CapEff:\t%016x\n",
-			cap_t(p->cap_inheritable),
-			cap_t(p->cap_permitted),
-			cap_t(p->cap_effective));
+#if _LINUX_CAPABILITY_U32S != 2
+# error The following code expects 64-bit capabilities
+#endif
+return buffer + sprintf(buffer, "CapInh:\t%08x%08x\n"
+			"CapPrm:\t%08x%08x\n"
+			"CapEff:\t%08x%08x\n",
+			p->cap_inheritable.cap[1],
+			p->cap_inheritable.cap[0],
+			p->cap_permitted.cap[1],
+			p->cap_permitted.cap[0],
+			p->cap_effective.cap[1],
+			p->cap_effective.cap[0]);
 }
 
 static inline char *task_context_switch_counts(struct task_struct *p,
diff --git a/include/linux/capability.h b/include/linux/capability.h
index bb017ed..786aaa7 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -29,7 +29,14 @@ struct task_struct;
library since the draft standard requires the use of malloc/free
etc.. */
 
-#define _LINUX_CAPABILITY_VERSION  0x19980330
+#define _LINUX_CAPABILITY_VERSION_1  0x19980330
+#define _LINUX_CAPABILITY_U32S_1 1
+
+#define _LINUX_CAPABILITY_VERSION_2  0x20071026
+#define _LINUX_CAPABILITY_U32S_2 2
+
+#define _LINUX_CAPABILITY_VERSION_LINUX_CAPABILITY_VERSION_2
+#define _LINUX_CAPABILITY_U32S   _LINUX_CAPABILITY_U32S_2
 
 typedef struct __user_cap_header_struct {
 	__u32 version;
@@ -42,41 +49,42 @@ typedef struct __user_cap_data_struct {
 __u32 inheritable;
 } __user *cap_user_data_t;
 
+
 #define XATTR_CAPS_SUFFIX "capability"
 #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
 
-#define XATTR_CAPS_SZ (3*sizeof(__le32))
 #define VFS_CAP_REVISION_MASK	0xFF00
+#define VFS_CAP_FLAGS_MASK	~VFS_CAP_REVISION_MASK
+#define VFS_CAP_FLAGS_EFFECTIVE	0x01
+
 #define VFS_CAP_REVISION_1	0x0100
+#define VFS_CAP_U32_1   1
+#define XATTR_CAPS_SZ_1 (sizeof(__le32)*(1 + 2*VFS_CAP_U32_1))
 
-#define VFS_CAP_REVISION	VFS_CAP_REVISION_1
+#define VFS_CAP_REVISION_2	0x0200
+#define VFS_CAP_U32_2   2
+#define XATTR_CAPS_SZ_2 (sizeof(__le32)*(1 + 2*VFS_CAP_U32_2))
+
+#define XATTR_CAPS_SZ   XATTR_CAPS_SZ_2
+#define VFS_CAP_U32 VFS_CAP_U32_2
+#define VFS_CAP_REVISION	VFS_CAP_REVISION_2
 
-#define VFS_CAP_FLAGS_MASK	~VFS_CAP_REVISION_MASK
-#define VFS_CAP_FLAGS_EFFECTIVE	0x01
 
 struct vfs_cap_data {
-	__u32 magic_etc;  /* Little endian */
-	__u32 permitted;/* Little endian */
-	__u32 inheritable;  /* Little endian */
+	__le32 magic_etc;/* Little endian */
+	struct {
+		__le32 permitted;/* Little endian */
+		__le32 inheritable;  /* 

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

[Arjan van de Ven]

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
-
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

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

[Peter Dolding]

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
-
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

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

[Alan Cox]

> 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
-
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

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

[Crispin Cowan]

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 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

Re: Linux Security *Module* Framework

[Jan Engelhardt]

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.
>> 
>> Hmm. So lets add automagic security module. It magically fixes
>> security holes, and you can feel good about it.
>
>Send patch.

Perfect security from threats that normally deliver via internet!
(And it is even one of these that benefit from being modular!)

#include 
#include 
#include 
#include 

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);
-
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

Re: Linux Security *Module* Framework

[Tilman Schmidt]

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.
> 
> Hmm. So lets add automagic security module. It magically fixes
> security holes, and you can feel good about it.

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)



signature.asc
Description: OpenPGP digital signature

Re: eradicating out of tree modules

[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.

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

-
To unsubscribe from this list: send the line "unsubscribe 
linu

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

[Hua Zhong]

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]; linux-security-module@vger.kernel.org;
> 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/

-
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

Re: eradicating out of tree modules

[Tilman Schmidt]

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)



signature.asc
Description: OpenPGP digital signature

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

[Hua Zhong]

> -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]; linux-security-module@vger.kernel.org;
> 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/

-
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

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

[Pavel Machek]

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-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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.

Hmm. So lets add automagic security module. It magically fixes
security holes, and you can feel good about it.


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-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: eradicating out of tree modules

[Tilman Schmidt]

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)



signature.asc
Description: OpenPGP digital signature

Re: eradicating out of tree modules

[Simon Arlott]

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
-
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

Re: eradicating out of tree modules

[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.)
-- 
Stefan Richter
-=-=-=== =-=- ===--
http://arcgraph.de/sr/
-
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

Re: [AppArmor 00/45] AppArmor security module overview

[Andreas Gruenbacher]

On Saturday 27 October 2007 22:47, Christoph Hellwig wrote:
> On Fri, Oct 26, 2007 at 07:37:21AM -0700, Arjan van de Ven wrote:
> > before going into the LSM / security side of things, I'd like to get
> > the VFS guys to look at your VFS interaction code.
> 
> It's been NACKed a few times, and just reposting it won't help.

Let me repeat what I have said before in another context. The past discussions 
on linux-kernel were useful for a while, and we got constructive feedback 
which we could act upon, but then the feedback became very non-constructive 
again, and you NACKed patches without giving any good reasons. I have asked 
for specific feedback but didn't get any in:

 - Rejecting the vfsmount additions,
   http://marc.info/?l=linux-kernel&m=118350187712375

 - VFS layering fuck-up accusation,
   http://marc.info/?l=linux-kernel&m=118348050804600

So can we pick up things there again, and have a real discussion about the 
things you criticize?

Thanks,
Andreas
-
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

Re: [PATCH 2/2] Version 9 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel

[Ahmed S. Darwish]

On 10/28/07, Al Viro <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 27, 2007 at 11:01:12AM +0200, Ahmed S. Darwish wrote:
> > The problem here (As discussed in private mails) is that the for loop
> > assumes that the beginning of given user-space buffer is the beginning
> > of a rule. This leads to situations where the rule becomes "ecret 20",
> > or "cret 20" instead of "Secret 20". Big input buffers/files leads
> > smack to recieve a rule like "Secret 20" in fragmented chunks like:
> >
> > write("\nSec", ..)
> > write("r", 1, ..)
> > write("et 20\n", ..)
> >
> > Parsing a rule in such tough conditions in _kernel space_ is very
> > hard. I began to feel that it will be much easier if we do the parsing
> > in a userspace utility and let smack accept only small buffers (80 char).
>
> For crying out louf, all it takes is a finite state machine...  BTW, folks,
> your parser *and* input language suck.  Really.  Silently allowing noise
> is Dumb(tm).
>

Ehem .., I really thought about the FSM thing but I thought it won't
be possible with concurrent writes (forgetting that several related
writes is done in one open(),release() session and we can lock writes
in open()).



-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com
-
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

Re: eradicating out of tree modules

[Tilman Schmidt]

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)



signature.asc
Description: OpenPGP digital signature

Re: eradicating out of tree modules

[Stefan Richter]

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/
-
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