--- Stephen Smalley wrote:

> On Mon, 2007-10-08 at 10:31 -0700, Casey Schaufler wrote:
> > ...
> > I wouldn't expect the whole thing to be more than a couple week's
> > work for someone who really wanted to do it.
>
> Note that Serge said "SELinux re-written on top of Smack", not "rewrite
> Smack to be more like SELinux".

Sorry, the subtlety of the difference seems insignificant to me.

> I don't believe the former is even
> possible, given that Smack is strictly less expressive and granular by
> design. Rewriting Smack to be more like SELinux should be possible,

As I outlined, it wouldn't be that hard to rewack SELinux from Smack.

> but seems like more work than emulating Smack on SELinux via policy,

Y'all keep saying that, but since noone has actually done that
SELinux policy, or anything like it, I maintain that it's not as
easy as you are inclined to claim. It is certainly not the "I'll
whip it up this weekend" sort of task that some have suggested.

> and to what end?

Well, there is that. I personally think that one implementation of
SELinux is plenty.

On the other hand, I think that if the concept of a single security
architecture has value the advocates of that position ought to be
looking at SELinux on/of Smack just as carefully as they look at
Smack on/of SELinux. If they are not, I suggest that the Single
Security Architecture argument is a sophistic device rather than
a legitimate issue of technology and should thus be ignored.


Casey Schaufler
casey@schaufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox writes:

>> My very practical question: How do I run selinux in one container,
>> and SMACK in another?
>
> In the LSM model you don't because you could have the same container
> objects visible in different contains at the same time and subject to
> different LSMs. What does it mean to pass an SELinux protected object
> over an AppArmour protected unix domain socket into a SMACK protected
> container ?

You raise a good point. My intuitive definition would go something like
this. In the initial LSM space we would have whatever is the primary
LSM and it would always be invoked about everything. However it
would view a single container (no matter what user in that container)
as having a single set of permissions. Then the LSM in the container
be asked to further validate accesses, but it would distinguish
between users in the container.

At this point it looks like if I am going to be effective at doing
anything I am going to need to step back watch SMACK get merged and
then really look at what the LSM modules are implementing. Then
I can refactor the whole mess and move additional functionality into
the LSM to help me achieve other things.

> Really its the same problem as "I'd like to use different file permission
> systems on different process identifiers" and it would be very hard to
> get right simply because objects can pass between two different security
> models.

Yep. Although the isolation of a container with a completely
different set of namespaces is tight enough that except for people
debugging a container from processes in the container from outside the
container object exchange essentially doesn't happen.

You do raise a very good question here. Does an LSM implement a
different file permission system? Or does an LSM implement a firewall
between processes?

Certainly selinux seems too programmable to be considered just a
different file permission system.

> Pyramid tried to do the "simple" case of BSD and System 5 on the same box
> and got caught out even with that because of the different rules on stuff
> like chgrp..

Yes. There are many hard problems here and many people have tried and
failed in the past. That hasn't stopped me before, and I don't see
why security should be any different.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
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-10 at 07:48 -0600, Eric W. Biederman wrote:
> Alan Cox writes:
>
> >> My very practical question: How do I run selinux in one container,
> >> and SMACK in another?
> >
> > In the LSM model you don't because you could have the same container
> > objects visible in different contains at the same time and subject to
> > different LSMs. What does it mean to pass an SELinux protected object
> > over an AppArmour protected unix domain socket into a SMACK protected
> > container ?
>
> You raise a good point. My intuitive definition would go something like
> this. In the initial LSM space we would have whatever is the primary
> LSM and it would always be invoked about everything. However it
> would view a single container (no matter what user in that container)
> as having a single set of permissions. Then the LSM in the container
> be asked to further validate accesses, but it would distinguish
> between users in the container.

SELinux internally has a notion of a type hierarchy, where a type is
limited to a subset of its parent's permissions, and one can then
delegate the ability to manage sub-types via a policy daemon. But this
is all handled in userspace; the kernel doesn't care about it.

Ditto for the modular policy support - that's a userspace construct that
is ultimately turned into a single coherent policy for the kernel to
enforce.

> At this point it looks like if I am going to be effective at doing
> anything I am going to need to step back watch SMACK get merged and
> then really look at what the LSM modules are implementing. Then
> I can refactor the whole mess and move additional functionality into
> the LSM to help me achieve other things.
>
> > Really its the same problem as "I'd like to use different file permission
> > systems on different process identifiers" and it would be very hard to
> > get right simply because objects can pass between two different security
> > models.
>
> Yep. Although the isolation of a container with a completely
> different set of namespaces is tight enough that except for people
> debugging a container from processes in the container from outside the
> container object exchange essentially doesn't happen.
>
> You do raise a very good question here. Does an LSM implement a
> different file permission system? Or does an LSM implement a firewall
> between processes?
>
> Certainly selinux seems too programmable to be considered just a
> different file permission system.

A LSM implements a security model, where that model may encompass all
processes and objects. SELinux (and Smack) in particular implement
mandatory access control and thus need to enforce consistent policy over
all processes and objects based on their security labels.

--
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

--- Stephen Smalley wrote:

> On Wed, 2007-10-10 at 07:48 -0600, Eric W. Biederman wrote:
> > Alan Cox writes:
> >
> > >> My very practical question: How do I run selinux in one container,
> > >> and SMACK in another?
> > >
> > > In the LSM model you don't because you could have the same container
> > > objects visible in different contains at the same time and subject to
> > > different LSMs. What does it mean to pass an SELinux protected object
> > > over an AppArmour protected unix domain socket into a SMACK protected
> > > container ?
> >
> > You raise a good point. My intuitive definition would go something like
> > this. In the initial LSM space we would have whatever is the primary
> > LSM and it would always be invoked about everything. However it
> > would view a single container (no matter what user in that container)
> > as having a single set of permissions. Then the LSM in the container
> > be asked to further validate accesses, but it would distinguish
> > between users in the container.
>
> SELinux internally has a notion of a type hierarchy, where a type is
> limited to a subset of its parent's permissions, and one can then
> delegate the ability to manage sub-types via a policy daemon. But this
> is all handled in userspace; the kernel doesn't care about it.
>
> Ditto for the modular policy support - that's a userspace construct that
> is ultimately turned into a single coherent policy for the kernel to
> enforce.
>
> > At this point it looks like if I am going to be effective at doing
> > anything I am going to need to step back watch SMACK get merged and
> > then really look at what the LSM modules are implementing. Then
> > I can refactor the whole mess and move additional functionality into
> > the LSM to help me achieve other things.

I think that you'll want to be careful with that approach.
Smack and SELinux both implement mandatory access control,
with very different mindsets too be sure, but MAC nonetheless.
Smack doesn't use any LSM hooks that SELinux doesn't. You
aren't going to get a very broad view of potential LSMs
comparing these two. AppArmor and TOMOYO are much more likely
to provide interesting alternative viewpoints. If you want to
get carried away factor the audit code in, too.

> > > Really its the same problem as "I'd like to use different file permission
> > > systems on different process identifiers" and it would be very hard to
> > > get right simply because objects can pass between two different security
> > > models.
> >
> > Yep. Although the isolation of a container with a completely
> > different set of namespaces is tight enough that except for people
> > debugging a container from processes in the container from outside the
> > container object exchange essentially doesn't happen.
> >
> > You do raise a very good question here. Does an LSM implement a
> > different file permission system? Or does an LSM implement a firewall
> > between processes?
> >
> > Certainly selinux seems too programmable to be considered just a
> > different file permission system.
>
> A LSM implements a security model, where that model may encompass all
> processes and objects. SELinux (and Smack) in particular implement
> mandatory access control and thus need to enforce consistent policy over
> all processes and objects based on their security labels.

What he said as far as Smack and SELinux go. Other models need not
encompass all processes and objects.


Casey Schaufler
casey@schaufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Ok, finally getting some time to work on this stuff once again (life
gets really crazy sometimes). I would like to postulate that you can
restate any SMACK policy as a functionally equivalent SELinux policy
(with a few slight technical differences, see below). I've been
working on a script to do this but keep getting stuck tracking down
minor bugs and then get dragged off on other things I need to do.
Here is the method I am presently trying to implement:

First divide the SELinux access vectors into 7 groups based on which
ones SMACK wishes to influence:
(R) Requires "read" permissions (the 'r' bit)
(W) Requires "write" permissions (the 'w' bit)
(X) Requires "execute" permissions (the 'x' bit)
(A) Requires "append" OR "write" permissions (the 'a' bit)
(P) Requires CAP_MAC_OVERRIDE
(K) May not be performed by a non-CAP_MAC_OVERRIDE process on a
CAP_MAC_OVERRIDE process
(N) Does not require any special permissions

The letters in front indicate the names I will use in the rest of
this document to describe the sets of access vectors.

Next define a single SELinux user "smack", and two independent roles,
"priv" and "unpriv". We create the set of SMACK equivalence-classes
defined as various SELinux types with substitutions for "*", "^",
"_", and "?", and then completely omit the MLS portions of the
SELinux policy.

The next step is to establish the fundamental constraints of the
policy. To prevent processes from gaining CAP_MAC_OVERRIDE we
iterate over the access vectors in (K) and add the following
constraint for each vector:
constrain $OBJECT_CLASS $ACCESS_VECTOR ((r1 == r2) || (r1 == priv))

This also includes:
constrain process transition ((r1 == r2) || (r1 == priv))

Then we require privilege to access the (P) vectors; for each vector
in (P) we add a constraint:
constrain $OBJECT_CLASS $ACCESS_VECTOR (r1 == priv)

At this point the only rules left to add are the between-type rules.
Here it gets mildly complicated because SMACK is a linear-lookup
system (each rule must be matched in order) whereas SELinux is a
globally-unique-lookup system (all rules are mutually exclusive and
matched simultaneously). Essentially for each SMACK rule:
$SOURCE $DEST $PERM_BITS

We iterate over all of the classes represented in the access vector
lists in $PERM_BITS and create rules for each one:
allow { $SOURCE } { $DEST }:$PERM_CLASS { $PERM_VECTORS };

If you need SMACK to allow subtractive permissions then you need to
expand that further, however I believe as an initial cut that it
sufficient.

The only other task is to prepend the auto-generated object-class and
access-vector lists to the policy and append the initial SIDs that
smack wants various objects to have, as well as allowing the "smack"
user the "priv" and "nopriv" roles and allowing those two roles entry
into all of the SMACK types. The resulting SELinux-ified SMACK
labels would go from:

SomeLabel (with CAP_MAC_OVERRIDE)
AnotherLabel
YetAnotherLabel

to:

smackriv:SomeLabel
smack:nopriv:AnotherLabel
smack:nopriv:YetAnotherLabel


Casey, hopefully this gives you some ideas about how I think you
could modify the SELinux code to compile out the "user" field and
simplify the "role" field as needed. I'm still not seeing anything
which SELinux cannot directly implement without additional code, even
the "CAP_MAC_OVERRIDE" bit. If the semantics don't seem quite right,
please provide details about how you think the models differ and I
will try to address the concerns.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

--- Kyle Moffett wrote:

> Ok, finally getting some time to work on this stuff once again (life
> gets really crazy sometimes). I would like to postulate that you can
> restate any SMACK policy as a functionally equivalent SELinux policy
> (with a few slight technical differences, see below). I've been
> working on a script to do this but keep getting stuck tracking down
> minor bugs and then get dragged off on other things I need to do.
> Here is the method I am presently trying to implement:
>
> First divide the SELinux access vectors into 7 groups based on which
> ones SMACK wishes to influence:
> (R) Requires "read" permissions (the 'r' bit)
> (W) Requires "write" permissions (the 'w' bit)
> (X) Requires "execute" permissions (the 'x' bit)
> (A) Requires "append" OR "write" permissions (the 'a' bit)
> (P) Requires CAP_MAC_OVERRIDE
> (K) May not be performed by a non-CAP_MAC_OVERRIDE process on a
> CAP_MAC_OVERRIDE process
> (N) Does not require any special permissions
>
> The letters in front indicate the names I will use in the rest of
> this document to describe the sets of access vectors.
>
> Next define a single SELinux user "smack", and two independent roles,
> "priv" and "unpriv". We create the set of SMACK equivalence-classes
> defined as various SELinux types with substitutions for "*", "^",
> "_", and "?", and then completely omit the MLS portions of the
> SELinux policy.
>
> The next step is to establish the fundamental constraints of the
> policy. To prevent processes from gaining CAP_MAC_OVERRIDE we
> iterate over the access vectors in (K) and add the following
> constraint for each vector:
> constrain $OBJECT_CLASS $ACCESS_VECTOR ((r1 == r2) || (r1 == priv))
>
> This also includes:
> constrain process transition ((r1 == r2) || (r1 == priv))
>
> Then we require privilege to access the (P) vectors; for each vector
> in (P) we add a constraint:
> constrain $OBJECT_CLASS $ACCESS_VECTOR (r1 == priv)
>
> At this point the only rules left to add are the between-type rules.
> Here it gets mildly complicated because SMACK is a linear-lookup
> system (each rule must be matched in order) whereas SELinux is a
> globally-unique-lookup system (all rules are mutually exclusive and
> matched simultaneously). Essentially for each SMACK rule:
> $SOURCE $DEST $PERM_BITS
>
> We iterate over all of the classes represented in the access vector
> lists in $PERM_BITS and create rules for each one:
> allow { $SOURCE } { $DEST }:$PERM_CLASS { $PERM_VECTORS };
>
> If you need SMACK to allow subtractive permissions then you need to
> expand that further, however I believe as an initial cut that it
> sufficient.
>
> The only other task is to prepend the auto-generated object-class and
> access-vector lists to the policy and append the initial SIDs that
> smack wants various objects to have, as well as allowing the "smack"
> user the "priv" and "nopriv" roles and allowing those two roles entry
> into all of the SMACK types. The resulting SELinux-ified SMACK
> labels would go from:
>
> SomeLabel (with CAP_MAC_OVERRIDE)
> AnotherLabel
> YetAnotherLabel
>
> to:
>
> smackriv:SomeLabel
> smack:nopriv:AnotherLabel
> smack:nopriv:YetAnotherLabel
>
>
> Casey, hopefully this gives you some ideas about how I think you
> could modify the SELinux code to compile out the "user" field and
> simplify the "role" field as needed. I'm still not seeing anything
> which SELinux cannot directly implement without additional code, even
> the "CAP_MAC_OVERRIDE" bit. If the semantics don't seem quite right,
> please provide details about how you think the models differ and I
> will try to address the concerns.

I'm still waiting to see the proposed SELinux policy that does
what Smack does. I can accept that you don't see anything that
can't be implemented thus, but that's not the point. You've
provided some really clear design notes, and that's great, but
it ain't the code. You said that you could write a 500 line
perl script that would do the whole thing, and that left some
people with an impression that Smack is a subset of SELinux.
Well, I'm already finding myself digging out from under that
missunderstanding, and with people who are assuming that your
policy has been done, "proving" the point.

I see nothing wrong with your approach, although I'm curious
about how your emulation of capabilities will work, or if it's
even rational to include in the SELinux context. I have my
benchmark lab* ready to go when you have a policy for me to try.

Thank you.

----
* It's a sony VAIO laptop with an 800MHZ AMD processor.


Casey Schaufler
casey@schaufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Oct 11, 2007, at 11:41:34, Casey Schaufler wrote:
> --- Kyle Moffett wrote:
>> [snipped]
>
> I'm still waiting to see the proposed SELinux policy that does what
> Smack does.

That *is* the SELinux policy which does what Smack does. I keep
having bugs in the perl-script I'm writing on account of not having
the time to really get around to fixing it, but that is exactly the
procedure for generating an SELinux policy from a SMACK policy.

> I can accept that you don't see anything that can't be implemented
> thus, but that's not the point. You've provided some really clear
> design notes, and that's great, but it ain't the code. You said
> that you could write a 500 line perl script that would do the whole
> thing, and that left some people with an impression that Smack is a
> subset of SELinux. Well, I'm already finding myself digging out
> from under that missunderstanding, and with people who are assuming
> that your policy has been done, "proving" the point.

I'd love to have time to finish the script but unfortunately real
life keeps interfering and I'm going to have to go back to lurking on
this thread.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> > from under that missunderstanding, and with people who are assuming
> > that your policy has been done, "proving" the point.
>
> I'd love to have time to finish the script but unfortunately real
> life keeps interfering and I'm going to have to go back to lurking on
> this thread.

How about posting the partial one you've got ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Dear, Folks,

Now we are planning to submit LIDS to mainline.
(As you know, it already written for supporing LSM for several years.)

When we will finish to re-write documentation and some FAQ, then
we will be able to submit the patch.

Sincerely,

OMO

Serge E. Hallyn wrote: (2007/10/09 03:00):
> Quoting Eric W. Biederman (ebiederm@xmission.com):
>> "Serge E. Hallyn" writes:
>> Also I'm thinking towards what do we have to do isolate the security
>> module stuff in the context of a namespace. So that a person in
>> a container can setup their own rules that further restrict the
>> system.
>
> In the selinux example I plan to do set up soon, that will be done
> using the '.' namespace separator.
>
> Every object/subject in vserver1 will have a type 'vserver1.whatever'.
> 'vserver1.root_t', 'vserver1.etc_t', etc.
>
> I don't know how far the policy tools have gotten, but they are
> *supposed* to implement constraints at policy compile time such that
> every type which is a child of 'vserver1' would have no more access than
> what is granted to type 'vserver1'. So this provides a pretty nice
> conceptual way to set up security for a vserver.
>
> Then using the userspace policy server and metapolicy (this would be a
> step or two beyond my first example) the policy could define rules about
> what sort of policy could be added by a process of type
> 'vserver1.root_t'. So we can allow the container admin to introduce
> policy changes affecting only his own container, and subject to all
> constraints placed by the host admin on vserver1.
>
>> So far I'm not ready to do anything yet but I'm keeping a weather eye
>> on the situation so I have a clue what I'm go.
>>
>>> If 1, an selinux policy should cover you. So you can then skip to 3.
>>> Or, alternatively, I do plan - as soon as my free time clears up a bit -
>>> on demonstrating how to write some selinux policy to create a secure
>>> container based on current -mm + your experimental network namespace
>>> patches.
>> Thanks that sounds interesting.
>>
>>> If 3, then selinux policy modules may actually help you, else either
>>> a new LSM (maybe like LIDS) or a userspace tool which is a front-end to
>>> selinux policy, emulating the iptables rules formats, may be what you
>>> want?
>> I don't want to have to choose my LSM at compile time. I want to
>> add support into the kernel at compile time and be able to configure
>> it before I go multi-user. I know this kind of architecture is
>> achievable because iptables allows it.
>>
>> When I conceive as the security modules as just a firewall between
>> applications on my own box I think, oh yeah this is no big deal,
>> I might want to limit something that way some time. These are just
>> some additional rules on when to return -EPERM. So I ask myself why
>> is this situation much less flexible and much harder to use then our
>> network firewall code?
>
> It actually used to be far more flexible than it is now. The consensus
> appears to be that it's just too hard - at times impossible - to
> properly label every object or subject at some point after they've all
> been created (processes created, inodes read from disk, etc). Two
> examples:
>
> 1. you've got pid 777. How was it created? Can you trust it's
> history? In my DTE module I solved this by keeping track of the
> *full* invocation history until a policy was loaded. I think
> tomoyo may do something similar. But it's really not
> sufficient, especially since you don't even want a LSM loaded
> at all. So you can't reduce it to 'boot_t executd init_t
> executed login_t executed shell_t', you have to keep track of
> every inode executed
>
> 2. how do you reliably re-evaluate, for some file, what label
> to assign to it? Do you guess at a pathname? Do you trust that
> the inodes have been pre-labeled for every LSM, so when you load
> the LSM you can grab the xattrs?
>
> So it's a valid question - do we address these sorts of concerns in
> order to add flexibility, or do we keep things as simple as possible
> and say that it's up to the distro, for instance, or a site local
> security administrator, to define policy, so that flexibility really
> is of very limited use?
>
>>>> My impression is that selinux is one monolithic blob that doesn't
>>>> allow me to incrementally add matching or action features that I
>>>> find interesting.
>>> Actually with policy modules it gets much much better. I have in fact
>>> been able to pretty easily write a short policy module to, say, create
>>> an selinux user which ran as root and had full access to the system to
>>> do system setup for automated testing. There is a learning curve in
>>> having to look at existing modules for maybe a few days to get started,
>>> but once you get started the policy modules do make it very easy to
>>> add to current policy.
>> Ok. Interesting. Are these kernel modules?
>
> Policy modules, loaded through selinuxfs at any time using 'semodule'.
>
>> Still while I get the general impression that selinux seems to be
>> very close to a generic solution, and that selinux more or less has
>> the architecture we might want. I don't get the impression that
>> selinux does this at a level that is open to other people doing
>> interesting things.
>>
>> So I still ask the question can we move this functionality down to
>> the LSM in a way that will solve the composition problem between
>> multiple security modules?
>
> I've tried At a less semantic and more purely technical level, using
> the stacker module. After a few years it was finally decided (at
> ksummit 2006) that it simply wasn't useful.
>
> Now perhaps the problem was that I didn't address semantic issues.
> But it does sound to me like what you want is a particular flexible LSM.
> Be it LIDS or SELinux, or something new.
>
>> It really seems to me that the LSM as currently structured creates
>> a large barrier to entry for people who have just this little thing
>> they want to do that is not possible with any existing security
>> module.
>
> Yes and it's been made increasingly so far particularly because of the
> perceived potential for 'abuse'. So to be curt, allowing people like
> you describe to do something small and interesting is deemed far less
> important than making sure that the small thing they want to do fits
> within the LSM mandate and is not a non-upstream module.
>
> So that is the concern you would need to address before any other.
>
> Still, I do think that selinux policy modules may do just what you want.
> The main obstacle appears to be that the 'base' policy is so huge that
> it's tough to get started to do something small.
>
> You also might want to check out LIDS, as its rules are set up pretty
> much the way you seem to want.
>
> -serge
> -
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>


--
Kazuki Omo: k-omo@sios.com
Group Manager, OSS Technology Center
Diary: http://omok.livejournal.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

--- "Kazuki Omo(Company)" wrote:

> Dear, Folks,
>
> Now we are planning to submit LIDS to mainline.
> (As you know, it already written for supporing LSM for several years.)
>
> When we will finish to re-write documentation and some FAQ, then
> we will be able to submit the patch.
>
> Sincerely,
>
> OMO

Most excellent. Thank you.


Casey Schaufler
casey@schaufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/