From: Casey Schaufler <casey@schaufler-ca.com>
To: Keith Owens <kaos@ocs.com.au>, casey@schaufler-ca.com
Cc: linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, akpm@osdl.org, torvalds@osdl.org
Subject: Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
Date: Sun, 12 Aug 2007 10:16:48 -0700 (PDT) [thread overview]
Message-ID: <318317.50626.qm@web36607.mail.mud.yahoo.com> (raw)
In-Reply-To: <3351.1186890318@ocs10w.ocs.com.au>
--- Keith Owens <kaos@ocs.com.au> 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"
> > "?" - pronounced "huh"
> >
> >The access rules enforced by Smack are, in order:
> >
> >1. Any access requested by a task labeled "*" is denied.
> >2. A read or execute access requested by a task labeled "^"
> > is permitted.
> >3. A read or execute access requested on an object labeled "_"
> > is permitted.
> >4. Any access requested on an object labeled "*" is permitted.
> >5. Any access requested by a task on an object with the same
> > label is permitted.
> >6. Any access requested that is explicitly defined in the loaded
> > rule set is permitted.
> >7. Any other access is denied.
>
> Some security systems that have the concept of "no default access"
> (task labeled "*") also allow access by those tasks but only if there
> is an explicit rule giving access to the task. IOW, rule 6 is applied
> before rule 1. In my experience this simplifies special cases where a
> task should only have access to a very small set of resources. I'm
> curious why smack goes the other way?
A task labeled star would create files labeled star, which would be
readable and writable by everyone (rule 4). This would be bad.
Over the past three decade I've seen a lot of secure installations
but I have never seen one where they really wanted to deny any
real application access to "/". That's a major reason for chrooted
environments.
Remember also that a process labeled Coffee would have read access
to floor files, all access to star files (e.g. /dev/null), read and
write access to Coffee objects, and no others unless specified. If
you are serious about reducing the programs a Coffee process can run
you can do so by moving them off the floor, that is, giving them
a different label, say "Tea". There is a cost to doing this, which
is that you now have to give other labels explicit access to Tea
objects. This is how you would implement a Biba integrity policy.
So, can you give me an example where you don't want access to any
file system objects (no read or execute access on floor) and are still
doing something useful? Remember that you can't exec a program if
you can't access it.
I think that access to the file system namespace is universally
required. I'm open to education.
Casey Schaufler
casey@schaufler-ca.com
prev parent reply other threads:[~2007-08-12 17:16 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-11 17:57 [PATCH] Smack: Simplified Mandatory Access Control Kernel Casey Schaufler
2007-08-11 19:12 ` Arjan van de Ven
2007-08-11 19:56 ` Casey Schaufler
2007-08-12 3:39 ` Keith Owens
2007-08-11 19:18 ` Kyle Moffett
2007-08-11 21:01 ` Casey Schaufler
2007-08-11 21:47 ` Kyle Moffett
2007-08-12 1:21 ` Casey Schaufler
2007-08-12 4:32 ` Kyle Moffett
2007-08-12 19:41 ` Casey Schaufler
2007-08-12 23:18 ` Crispin Cowan
2007-08-13 1:38 ` Kyle Moffett
2007-08-13 2:36 ` Joshua Brindle
2007-08-13 2:45 ` Kyle Moffett
2007-08-13 4:23 ` Casey Schaufler
2007-08-16 20:58 ` Pavel Machek
2007-08-17 4:56 ` Casey Schaufler
2007-08-17 9:46 ` Miguel Ojeda
2007-08-18 5:29 ` Kyle Moffett
2007-08-19 21:12 ` Valdis.Kletnieks
2007-08-21 13:16 ` Kyle Moffett
2007-08-21 15:50 ` Casey Schaufler
2007-08-22 3:43 ` Kyle Moffett
2007-08-22 4:08 ` Casey Schaufler
2007-09-07 16:02 ` Casey Schaufler
2007-08-20 14:29 ` Casey Schaufler
2007-08-21 7:37 ` Pavel Machek
2007-08-21 15:35 ` Casey Schaufler
2007-08-22 8:05 ` Pavel Machek
2007-08-22 18:47 ` Casey Schaufler
2007-08-23 7:14 ` Jan Engelhardt
2007-08-11 20:26 ` Jan Engelhardt
2007-08-11 23:22 ` Casey Schaufler
2007-08-12 11:16 ` Jan Engelhardt
2007-08-12 19:50 ` Casey Schaufler
2007-08-11 23:14 ` Andi Kleen
2007-08-12 1:36 ` Casey Schaufler
2007-08-12 11:49 ` Andi Kleen
2007-08-12 17:48 ` Casey Schaufler
2007-08-12 21:36 ` Andi Kleen
2007-08-12 21:46 ` Casey Schaufler
2007-08-12 3:45 ` Keith Owens
2007-08-12 17:16 ` Casey Schaufler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=318317.50626.qm@web36607.mail.mud.yahoo.com \
--to=casey@schaufler-ca.com \
--cc=akpm@osdl.org \
--cc=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox