Research
.
Skip Search Box

SELinux Mailing List

Re: [RFC & PATCH] inherited type definition.

From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net>
Date: Wed, 16 Mar 2005 10:00:34 +0000


On Wed, Mar 16, 2005 at 01:42:56PM +0900, Kaigai Kohei wrote:

> I have an idea that ALLOW statement is added an new option
> For example:
> ALLOW @user_t @user_t:process {ptrace};
> ALLOW user_t @user_t:process {transition};
>
> When '@' is added in front of the type name, this means source/target
> type is only user_t, not including user_ext_t and descendant.
> Above example is rolled out as follows:
> ALLOW user_t user_t:process {ptrace};
> ALLOW {user_t user_ext_t}:process {transition};

 that i like.

 an "after-the-fact" scheme i don't [one where you inherit and then  specify what you _don't_ want to be included].

 an explicit marker on parent rules saying "you can't inherit this"  i like.

 i like best the one which explicity says "all these rules within these  curly braces are inheritable".

 positive statements, the default being "nothing is inheritable",  matches up better with the "mandatory access control" methodology.  

 no assumptions. nothing granted by mistake. always explicitly say  what's allowed.

 l.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
Received on Wed 16 Mar 2005 - 04:56:56 EST
 

Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009

 
bottom

National Security Agency / Central Security Service