linux-kernel - Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 12 Aug 2007 10:16:48 -0700 (PDT)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Keith Owens <kaos@....com.au>, casey@...aufler-ca.com
Cc:	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, akpm@...l.org, torvalds@...l.org
Subject: Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel 

--- Keith Owens <kaos@....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@...aufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/