--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> ...
>
> As for the script, I'm partway through debugging it but my time is
> all chewed up with other stuff now, so it may take me an extra couple
> days.
Any progress on this?
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this
--- Kyle Moffett [EMAIL PROTECTED] wrote:
...
As for the script, I'm partway through debugging it but my time is
all chewed up with other stuff now, so it may take me an extra couple
days.
Any progress on this?
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send
On Aug 22 2007 11:47, Casey Schaufler wrote:
>> As we have to maintain selinux, anyway, I don't see why simplification
>> layer is a problem.
>
>It's an issue if you want to do simple things, have the resources to
>do simple things, but go over budget because the simple things are
>built on top
On Aug 22 2007 11:47, Casey Schaufler wrote:
As we have to maintain selinux, anyway, I don't see why simplification
layer is a problem.
It's an issue if you want to do simple things, have the resources to
do simple things, but go over budget because the simple things are
built on top of
--- Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > > but you written it in wrong language. You
> > > written it in C, while you should have written it in SELinux policy
> > > language (and your favourite scripting language as frontend).
> >
> > I have often marvelled at the notion of a
> > but you written it in wrong language. You
> > written it in C, while you should have written it in SELinux policy
> > language (and your favourite scripting language as frontend).
>
> I have often marvelled at the notion of a simplification layer.
> I believe that you build complex things on
but you written it in wrong language. You
written it in C, while you should have written it in SELinux policy
language (and your favourite scripting language as frontend).
I have often marvelled at the notion of a simplification layer.
I believe that you build complex things on top of
--- Pavel Machek [EMAIL PROTECTED] wrote:
but you written it in wrong language. You
written it in C, while you should have written it in SELinux policy
language (and your favourite scripting language as frontend).
I have often marvelled at the notion of a simplification layer.
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 21, 2007, at 11:50:48, Casey Schaufler wrote:
> > --- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> >> Well, in this case the "box" I want to secure will eventually be
> >> running multi-user X on a multi-level-with-IPsec network. For
> >>
On Aug 21, 2007, at 11:50:48, Casey Schaufler wrote:
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
Well, in this case the "box" I want to secure will eventually be
running multi-user X on a multi-level-with-IPsec network. For
that kind of protection profile, there is presently no substitute
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 19, 2007, at 17:12:41, [EMAIL PROTECTED] wrote:
> > On Sat, 18 Aug 2007 01:29:58 EDT, Kyle Moffett said:
> >> If you can show me a security system other than SELinux which is
> >> sufficiently flexible to secure those 2 million lines of code
--- Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > Ergo the only
> > > people who should be writing security policy for deployment are those
> > > people who have studied and trained in the stuff. Those people are
> > > also known as "security professionals".
> >
> > If only
On Aug 19, 2007, at 17:12:41, [EMAIL PROTECTED] wrote:
On Sat, 18 Aug 2007 01:29:58 EDT, Kyle Moffett said:
If you can show me a security system other than SELinux which is
sufficiently flexible to secure those 2 million lines of code
along with the other 50 million lines of code found in
Hi!
> > Ergo the only
> > people who should be writing security policy for deployment are those
> > people who have studied and trained in the stuff. Those people are
> > also known as "security professionals".
>
> If only security professionals can use the system you have failed
> to
On Aug 21, 2007, at 11:50:48, Casey Schaufler wrote:
--- Kyle Moffett [EMAIL PROTECTED] wrote:
Well, in this case the box I want to secure will eventually be
running multi-user X on a multi-level-with-IPsec network. For
that kind of protection profile, there is presently no substitute
for
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 21, 2007, at 11:50:48, Casey Schaufler wrote:
--- Kyle Moffett [EMAIL PROTECTED] wrote:
Well, in this case the box I want to secure will eventually be
running multi-user X on a multi-level-with-IPsec network. For
that kind of
Hi!
Ergo the only
people who should be writing security policy for deployment are those
people who have studied and trained in the stuff. Those people are
also known as security professionals.
If only security professionals can use the system you have failed
to provide a
On Aug 19, 2007, at 17:12:41, [EMAIL PROTECTED] wrote:
On Sat, 18 Aug 2007 01:29:58 EDT, Kyle Moffett said:
If you can show me a security system other than SELinux which is
sufficiently flexible to secure those 2 million lines of code
along with the other 50 million lines of code found in
--- Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
Ergo the only
people who should be writing security policy for deployment are those
people who have studied and trained in the stuff. Those people are
also known as security professionals.
If only security professionals can
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 19, 2007, at 17:12:41, [EMAIL PROTECTED] wrote:
On Sat, 18 Aug 2007 01:29:58 EDT, Kyle Moffett said:
If you can show me a security system other than SELinux which is
sufficiently flexible to secure those 2 million lines of code
along
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> Finally moved back in and with internet. Yay!
>
> On Aug 17, 2007, at 00:56:44, Casey Schaufler wrote:
> > It would not surprise me particularly much if Kyle or someone like
> > him could produce a perl script that could generate an SELinux
> >
--- Kyle Moffett [EMAIL PROTECTED] wrote:
Finally moved back in and with internet. Yay!
On Aug 17, 2007, at 00:56:44, Casey Schaufler wrote:
It would not surprise me particularly much if Kyle or someone like
him could produce a perl script that could generate an SELinux
policy
On Sat, 18 Aug 2007 01:29:58 EDT, Kyle Moffett said:
> XFCE. If you can show me a security system other than SELinux which
> is sufficiently flexible to secure those 2 million lines of code
> along with the other 50 million lines of code found in various pieces
> of software on my Debian
On Sat, 18 Aug 2007 01:29:58 EDT, Kyle Moffett said:
XFCE. If you can show me a security system other than SELinux which
is sufficiently flexible to secure those 2 million lines of code
along with the other 50 million lines of code found in various pieces
of software on my Debian box
Finally moved back in and with internet. Yay!
On Aug 17, 2007, at 00:56:44, Casey Schaufler wrote:
It would not surprise me particularly much if Kyle or someone like
him could produce a perl script that could generate an SELinux
policy that, when added to the reference policy on a system
Btw, at:
diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
linux-2.6.22-base/security/smack/Kconfig
linux-2.6.22/security/smack/Kconfig
--- linux-2.6.22-base/security/smack/Kconfig1969-12-31
16:00:00.0 -0800
+++ linux-2.6.22/security/smack/Kconfig 2007-07-10 01:08:05.0
Btw, at:
diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
linux-2.6.22-base/security/smack/Kconfig
linux-2.6.22/security/smack/Kconfig
--- linux-2.6.22-base/security/smack/Kconfig1969-12-31
16:00:00.0 -0800
+++ linux-2.6.22/security/smack/Kconfig 2007-07-10 01:08:05.0
Finally moved back in and with internet. Yay!
On Aug 17, 2007, at 00:56:44, Casey Schaufler wrote:
It would not surprise me particularly much if Kyle or someone like
him could produce a perl script that could generate an SELinux
policy that, when added to the reference policy on a system
--- Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > I will write you a Perl script which will generate a complete
> > > and functionally equivalent SELinux policy (assuming I have enough
> > > free time) given a file with your policy language. But I can do this
> > > if and only if
Hi!
> > I will write you a Perl script which will generate a complete
> > and functionally equivalent SELinux policy (assuming I have enough
> > free time) given a file with your policy language. But I can do this
> > if and only if you tell me which of the SELinux access vectors you
> >
Hi!
I will write you a Perl script which will generate a complete
and functionally equivalent SELinux policy (assuming I have enough
free time) given a file with your policy language. But I can do this
if and only if you tell me which of the SELinux access vectors you
care
--- Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
I will write you a Perl script which will generate a complete
and functionally equivalent SELinux policy (assuming I have enough
free time) given a file with your policy language. But I can do this
if and only if you tell me
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
>
>
> If you have no interest in categorizing the SELinux access vectors,
> then how do you expect to categorize the LSM hooks, which are almost
> 1-to-1 mapped with the SELinux access vectors?
Those that refer to object accesses and those that
Kyle Moffett wrote:
On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote:
Your boolean solution requires more forthought than the Smack rule
solution, but I'll give it to you once you've fleshed out your "##"
lines.
How does it require more forethought? When I want to turn it on, I
write
On Aug 12, 2007, at 22:36:15, Joshua Brindle wrote:
Kyle Moffett wrote:
On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote:
Your boolean solution requires more forthought than the Smack
rule solution, but I'll give it to you once you've fleshed out
your "##" lines.
How does it require
On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote:
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
On Aug 11, 2007, at 21:21:55, Casey Schaufler wrote:
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
I was considering compiling the complete list, but such an
exercise would take me at least an hour
Casey Schaufler wrote:
> I respect the design decisions that SELinux has made regarding
> granularity without agreeing with them myself.
>
It isn't even an exclusive decision: both design points can be "right",
but aimed at different use cases. Which is why LSM exists, so users can
decide on
--- Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 12, 2007 at 10:48:05AM -0700, Casey Schaufler wrote:
> >
> > --- Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > > > Entries are never deleted, although they can be modified.
> > >
> > > The modification case still seems racy then.
> >
>
On Sun, Aug 12, 2007 at 10:48:05AM -0700, Casey Schaufler wrote:
>
> --- Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > Entries are never deleted, although they can be modified.
> >
> > The modification case still seems racy then.
>
> Fair enough. I'll look into real list management.
You don't
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >> >+static int smack_task_movememory(struct task_struct *p)
> >> >+{
> >> >+ int rc;
> >> >+
> >> >+ rc = smk_curacc(smk_of_task(p), MAY_WRITE);
> >> >+ return rc;
> >> >+}
> >>
> >> Uh...
> >>
> >> {
> >>return smk_curacc(smk_of_task(p),
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> Linus and AKPM pulled from CC, I'm sure they're bored to tears by
> now ;-).
Yeah.
> On Aug 11, 2007, at 21:21:55, Casey Schaufler wrote:
> > --- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> >> On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
>
--- Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Entries are never deleted, although they can be modified.
>
> The modification case still seems racy then.
Fair enough. I'll look into real list management.
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
--- Keith Owens <[EMAIL PROTECTED]> wrote:
> Casey Schaufler (on Sat, 11 Aug 2007 10:57:31 -0700) wrote:
> >Smack is the Simplified Mandatory Access Control Kernel.
> >
> > [snip]
> >
> >Smack defines and uses these labels:
> >
> >"*" - pronounced "star"
> >"_" - pronounced "floor"
> >
> Entries are never deleted, although they can be modified.
The modification case still seems racy then.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Aug 11 2007 16:22, Casey Schaufler wrote:
>> >@@ -0,0 +1,8 @@
>> >+#
>> >+# Makefile for the SMACK LSM
>> >+#
>> >+
>> >+obj-$(CONFIG_SECURITY_SMACK) := smack.o
>> >+
>> >+smack-y := smack_lsm.o smack_access.o smackfs.o
>>
>> smack-objs :=
>
>Added.
I should have added "replace it".
>> >+/*
On Aug 12, 2007, at 22:36:15, Joshua Brindle wrote:
Kyle Moffett wrote:
On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote:
Your boolean solution requires more forthought than the Smack
rule solution, but I'll give it to you once you've fleshed out
your ## lines.
How does it require more
Kyle Moffett wrote:
On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote:
Your boolean solution requires more forthought than the Smack rule
solution, but I'll give it to you once you've fleshed out your ##
lines.
How does it require more forethought? When I want to turn it on, I
write and
--- Kyle Moffett [EMAIL PROTECTED] wrote:
really big snip
If you have no interest in categorizing the SELinux access vectors,
then how do you expect to categorize the LSM hooks, which are almost
1-to-1 mapped with the SELinux access vectors?
Those that refer to object accesses and
On Aug 11 2007 16:22, Casey Schaufler wrote:
@@ -0,0 +1,8 @@
+#
+# Makefile for the SMACK LSM
+#
+
+obj-$(CONFIG_SECURITY_SMACK) := smack.o
+
+smack-y := smack_lsm.o smack_access.o smackfs.o
smack-objs :=
Added.
I should have added replace it.
+/*
+ * ' \n\0'
Entries are never deleted, although they can be modified.
The modification case still seems racy then.
-Andi
-
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
--- Keith Owens [EMAIL PROTECTED] wrote:
Casey Schaufler (on Sat, 11 Aug 2007 10:57:31 -0700) wrote:
Smack is the Simplified Mandatory Access Control Kernel.
[snip]
Smack defines and uses these labels:
* - pronounced star
_ - pronounced floor
^ - pronounced hat
? -
--- Andi Kleen [EMAIL PROTECTED] wrote:
Entries are never deleted, although they can be modified.
The modification case still seems racy then.
Fair enough. I'll look into real list management.
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe
--- Kyle Moffett [EMAIL PROTECTED] wrote:
Linus and AKPM pulled from CC, I'm sure they're bored to tears by
now ;-).
Yeah.
On Aug 11, 2007, at 21:21:55, Casey Schaufler wrote:
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
It would be
--- Jan Engelhardt [EMAIL PROTECTED] wrote:
+static int smack_task_movememory(struct task_struct *p)
+{
+ int rc;
+
+ rc = smk_curacc(smk_of_task(p), MAY_WRITE);
+ return rc;
+}
Uh...
{
return smk_curacc(smk_of_task(p), MAY_WRITE);
}
(also others)
That was
On Sun, Aug 12, 2007 at 10:48:05AM -0700, Casey Schaufler wrote:
--- Andi Kleen [EMAIL PROTECTED] wrote:
Entries are never deleted, although they can be modified.
The modification case still seems racy then.
Fair enough. I'll look into real list management.
You don't necessarily
--- Andi Kleen [EMAIL PROTECTED] wrote:
On Sun, Aug 12, 2007 at 10:48:05AM -0700, Casey Schaufler wrote:
--- Andi Kleen [EMAIL PROTECTED] wrote:
Entries are never deleted, although they can be modified.
The modification case still seems racy then.
Fair enough. I'll look
Casey Schaufler wrote:
I respect the design decisions that SELinux has made regarding
granularity without agreeing with them myself.
It isn't even an exclusive decision: both design points can be right,
but aimed at different use cases. Which is why LSM exists, so users can
decide on an
On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote:
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 11, 2007, at 21:21:55, Casey Schaufler wrote:
--- Kyle Moffett [EMAIL PROTECTED] wrote:
I was considering compiling the complete list, but such an
exercise would take me at least an hour to
Linus and AKPM pulled from CC, I'm sure they're bored to tears by
now ;-).
On Aug 11, 2007, at 21:21:55, Casey Schaufler wrote:
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
It would be instructive for those who are not well versed in the
Casey Schaufler (on Sat, 11 Aug 2007 10:57:31 -0700) wrote:
>Smack is the Simplified Mandatory Access Control Kernel.
>
> [snip]
>
>Smack defines and uses these labels:
>
>"*" - pronounced "star"
>"_" - pronounced "floor"
>"^" - pronounced "hat"
>"?" - pronounced "huh"
>
>The
Casey Schaufler (on Sat, 11 Aug 2007 12:56:42 -0700 (PDT)) wrote:
>
>--- Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include "../../net/netlabel/netlabel_domainhash.h"
>>
>> can't you move this header to
--- Andi Kleen <[EMAIL PROTECTED]> wrote:
> Casey Schaufler <[EMAIL PROTECTED]> writes:
>
> > Smack is the Simplified Mandatory Access Control Kernel.
>
> I like the simplified part.
>
> > +static int smk_get_access(smack_t sub, smack_t obj)
> > +{
> > + struct smk_list_entry *sp =
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
> >> [SELinux...] which can do *all* of this, completely and without
> >> exceptions,
> >
> > That's quite a strong assertion.
>
> It is, but I stand by it. If anyone can point out some portion
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Aug 11 2007 10:57, Casey Schaufler wrote:
> >
> >"*" - pronounced "star"
> wall
> >"_" - pronounced "floor"
> floor
> >"^" - pronounced "hat"
> roof
> >"?" - pronounced "huh"
> it's dark in here :)
It's almost worth
Casey Schaufler <[EMAIL PROTECTED]> writes:
> Smack is the Simplified Mandatory Access Control Kernel.
I like the simplified part.
> +static int smk_get_access(smack_t sub, smack_t obj)
> +{
> + struct smk_list_entry *sp = smack_list;
> +
> + for (; sp != NULL; sp = sp->smk_next)
> +
On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
[SELinux...] which can do *all* of this, completely and without
exceptions,
That's quite a strong assertion.
It is, but I stand by it. If anyone can point out some portion of
this which *cannot* be implemented as SELinux policy I will
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 11, 2007, at 13:57:31, Casey Schaufler wrote:
> > Smack implements mandatory access control (MAC) using labels
> > attached to tasks and data containers, including files, SVIPC, and
> > other tasks. Smack is a kernel based scheme that
On Aug 11 2007 10:57, Casey Schaufler wrote:
>
>"*" - pronounced "star"
wall
>"_" - pronounced "floor"
floor
>"^" - pronounced "hat"
roof
>"?" - pronounced "huh"
it's dark in here :)
>+config SECURITY_SMACK
>+ bool "Simplified Mandatory Access Control Kernel Support"
>+
--- Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > +extern struct smk_list_entry *smack_list;
>
> any reason to invent your own list rather than just using list.h?
The list.h mechanisms are fine, but heavier than I require.
I'm willing to give in on it, but I don't see an advantage.
> > +
>
On Aug 11, 2007, at 13:57:31, Casey Schaufler wrote:
Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC, and
other tasks. Smack is a kernel based scheme that requires an
absolute minimum of application support and a
> +extern struct smk_list_entry *smack_list;
any reason to invent your own list rather than just using list.h?
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "../../net/netlabel/netlabel_domainhash.h"
can't you move this header to include/ instead?
> +
>
+extern struct smk_list_entry *smack_list;
any reason to invent your own list rather than just using list.h?
+
+#include linux/kernel.h
+#include linux/vmalloc.h
+#include linux/security.h
+#include linux/mutex.h
+#include net/netlabel.h
+#include
On Aug 11, 2007, at 13:57:31, Casey Schaufler wrote:
Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC, and
other tasks. Smack is a kernel based scheme that requires an
absolute minimum of application support and a
--- Arjan van de Ven [EMAIL PROTECTED] wrote:
+extern struct smk_list_entry *smack_list;
any reason to invent your own list rather than just using list.h?
The list.h mechanisms are fine, but heavier than I require.
I'm willing to give in on it, but I don't see an advantage.
+
On Aug 11 2007 10:57, Casey Schaufler wrote:
* - pronounced star
wall
_ - pronounced floor
floor
^ - pronounced hat
roof
? - pronounced huh
it's dark in here :)
+config SECURITY_SMACK
+ bool Simplified Mandatory Access Control Kernel Support
+ depends on NETLABEL
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 11, 2007, at 13:57:31, Casey Schaufler wrote:
Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC, and
other tasks. Smack is a kernel based scheme that requires an
On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
[SELinux...] which can do *all* of this, completely and without
exceptions,
That's quite a strong assertion.
It is, but I stand by it. If anyone can point out some portion of
this which *cannot* be implemented as SELinux policy I will
Casey Schaufler [EMAIL PROTECTED] writes:
Smack is the Simplified Mandatory Access Control Kernel.
I like the simplified part.
+static int smk_get_access(smack_t sub, smack_t obj)
+{
+ struct smk_list_entry *sp = smack_list;
+
+ for (; sp != NULL; sp = sp-smk_next)
+
--- Jan Engelhardt [EMAIL PROTECTED] wrote:
On Aug 11 2007 10:57, Casey Schaufler wrote:
* - pronounced star
wall
_ - pronounced floor
floor
^ - pronounced hat
roof
? - pronounced huh
it's dark in here :)
It's almost worth considering the change for the joke.
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
[SELinux...] which can do *all* of this, completely and without
exceptions,
That's quite a strong assertion.
It is, but I stand by it. If anyone can point out some portion of
this
--- Andi Kleen [EMAIL PROTECTED] wrote:
Casey Schaufler [EMAIL PROTECTED] writes:
Smack is the Simplified Mandatory Access Control Kernel.
I like the simplified part.
+static int smk_get_access(smack_t sub, smack_t obj)
+{
+ struct smk_list_entry *sp = smack_list;
+
+ for
Casey Schaufler (on Sat, 11 Aug 2007 12:56:42 -0700 (PDT)) wrote:
--- Arjan van de Ven [EMAIL PROTECTED] wrote:
+#include linux/kernel.h
+#include linux/vmalloc.h
+#include linux/security.h
+#include linux/mutex.h
+#include net/netlabel.h
+#include
Casey Schaufler (on Sat, 11 Aug 2007 10:57:31 -0700) wrote:
Smack is the Simplified Mandatory Access Control Kernel.
[snip]
Smack defines and uses these labels:
* - pronounced star
_ - pronounced floor
^ - pronounced hat
? - pronounced huh
The access rules enforced by Smack
Linus and AKPM pulled from CC, I'm sure they're bored to tears by
now ;-).
On Aug 11, 2007, at 21:21:55, Casey Schaufler wrote:
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 11, 2007, at 17:01:09, Casey Schaufler wrote:
It would be instructive for those who are not well versed in the
84 matches
Mail list logo
