--- 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:
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 simplific
> > 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
--- 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
> >> tha
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 secur
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 var
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 prov
--- 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
> >
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 bo
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
d
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 -07
--- 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
> >
--- 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 d
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 an
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 mor
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 an
--- 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), MA
--- 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 "unsubscr
--- 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 http://vger.kernel.org/majordomo-info.htm
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".
>> >+/*
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
n
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
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 include
--- 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_lis
--- 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 considerin
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 h
--- 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 requi
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 very
> +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?
> +
> +s
42 matches
Mail list logo
