Are the reference policy abstractions the right ones?

Are the reference policy abstractions the right ones?

[James Carter]

I would like to start a discussion on whether reference policy is
providing the right abstractions for writing policy.

This is not intended to be an attack on Chris or Dan, or their work.  I
think that it is obvious that reference policy is much better organized,
far more useful, and works way better than the old example policy.  We
don't want to go back to example policy.

One of the goals of reference policy is to provide a more modern feel to
the policy by eliminating the use of types in a global manner across the
whole policy.  It does this by allowing interfaces to be defined through
which permissions can be granted to the types of a module.  There seems
to be several problems with this.

1) The user is constantly presented with types.  They are in the audit
logs, when the label of a process or file is displayed, and even in the
man pages ("Set cgi scripts with httpd_sys_script_exec_t to allow them
to run with access to all sys types.")

2) We have traded needing to know about 2500 types or so to write
policy, for needing to know around 4000 interfaces.  And no, I don't
think that SELinux Clippy is the answer.

3) We don't need to abstract class and permissions, because they don't
change very much, but frequently the interfaces consist of only a few
allow rules.  Over 60% of the interfaces have only one line (not
counting gen_require or refpolicywarn lines).
Lines   # of Interfaces
     0    53	These only have a refpolicywarn line
     1  3080    Around 300 of these consist of a single dontaudit rule
     2  1224
     3   269
     4    80
     5    29
     6    14
     7    11
     8    10
     9     5
    10     7
 11-50    17
51-100     2
  >100     0

It is true that some to many of these are calling other interfaces or
macros, so they are a little bit longer than indicated here.  Templates
are much more useful, but there are still many very short ones.
Lines   # of Templates
     1    51
     2    32
     3    12
     4     7
     5     5
     6     3
     7     1
     8     4
     9     2
    10     1
 11-50    34
51-100    24
  >100    21


I think that we need:

1) A way to say, "I want a domain like that one, without this
permission, but with that one".  I think that inheritance is the answer,
because a macro requires you to know ahead of time that someone might be
interested in making something similar.  I believe that Karl tried to
start a discussion on inheritance a month ago, but there wasn't any
interest.  Let's restart that discussion.  I think that whether through
macros or inheritance, a rule to remove permissions is needed, because
without one, we have to get the base classes or macros perfect.

2) A way to export types in some manner that would still allow
flexibility in renaming or splitting a type locally, without having to
change the global name.  That global name would also have to be what
shows up in audit logs and other things.  Maybe this is impossible and
we are just stuck treating types as global entities.

-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency


--
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.

Re: Are the reference policy abstractions the right ones?

[Karl MacMillan]

On Tue, 2007-10-09 at 11:08 -0400, James Carter wrote:
[...]
> 
> 1) A way to say, "I want a domain like that one, without this
> permission, but with that one".  I think that inheritance is the answer,
> because a macro requires you to know ahead of time that someone might be
> interested in making something similar.  I believe that Karl tried to
> start a discussion on inheritance a month ago, but there wasn't any
> interest.  Let's restart that discussion.  I think that whether through
> macros or inheritance, a rule to remove permissions is needed, because
> without one, we have to get the base classes or macros perfect.
> 

Like I said I think this would be useful.

> 2) A way to export types in some manner that would still allow
> flexibility in renaming or splitting a type locally, without having to
> change the global name.  That global name would also have to be what
> shows up in audit logs and other things.  Maybe this is impossible and
> we are just stuck treating types as global entities.
> 

It occurs to me that removing the distinction between types and
attributes and allowing nesting of them gets a lot of this. Say you have
a type:

type foo;

allow foo etc_t : file read;
allow foo self : process signal;

If you could then just say:

type bar, foo;

I.e., treat foo as an attribute. That would handle the type splitting
issues for files as well. Nested attributes would also allow building up
of more complex attributes:

attribute domain;
# rules for a process

attribute daemon, domain;
# daemon is also a domain. Add rules related
# to being a daemon

attribute network_server, daemon;
# A daemon that can talk on the network.

Karl


--
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.

Re: Are the reference policy abstractions the right ones?

[Joshua Brindle]

James Carter wrote:
> I would like to start a discussion on whether reference policy is
> providing the right abstractions for writing policy.
>
> This is not intended to be an attack on Chris or Dan, or their work.  I
> think that it is obvious that reference policy is much better organized,
> far more useful, and works way better than the old example policy.  We
> don't want to go back to example policy.
>
> One of the goals of reference policy is to provide a more modern feel to
> the policy by eliminating the use of types in a global manner across the
> whole policy.  It does this by allowing interfaces to be defined through
> which permissions can be granted to the types of a module.  There seems
> to be several problems with this.
>
> 1) The user is constantly presented with types.  They are in the audit
> logs, when the label of a process or file is displayed, and even in the
> man pages ("Set cgi scripts with httpd_sys_script_exec_t to allow them
> to run with access to all sys types.")
>
>   


We've been talking about this here as well. I think its clear that types 
should either be global in policy and implementation or they should not 
be global. The latter means sticking with the kinds of abstraction in 
refpolicy but extending it so that audit logs and on-disk labels are 
both presented with those abstractions. This means potentially making 
the kernel implementation of SELinux more complicated but completing the 
currently ill-fated abstractions that we have.

> 2) We have traded needing to know about 2500 types or so to write
> policy, for needing to know around 4000 interfaces.  And no, I don't
> think that SELinux Clippy is the answer.
>
>   

The interfaces have documentation and are well organized where types 
aren't (they aren't even consistent in naming because of legacy names 
being used).

> 3) We don't need to abstract class and permissions, because they don't
> change very much, but frequently the interfaces consist of only a few
> allow rules.  Over 60% of the interfaces have only one line (not
> counting gen_require or refpolicywarn lines).
> Lines   # of Interfaces
>      0    53	These only have a refpolicywarn line
>      1  3080    Around 300 of these consist of a single dontaudit rule
>   

not too surprising, think of these like OO accessors :) The unfortunate 
part is that the symbols still end up globally (which is the other part 
of the problem).

>      2  1224
>      3   269
>      4    80
>      5    29
>      6    14
>      7    11
>      8    10
>      9     5
>     10     7
>  11-50    17
> 51-100     2
>   >100     0
>
> It is true that some to many of these are calling other interfaces or
> macros, so they are a little bit longer than indicated here.  Templates
> are much more useful, but there are still many very short ones.
> Lines   # of Templates
>      1    51
>      2    32
>      3    12
>      4     7
>      5     5
>      6     3
>      7     1
>      8     4
>      9     2
>     10     1
>  11-50    34
> 51-100    24
>   >100    21
>
>
> I think that we need:
>
> 1) A way to say, "I want a domain like that one, without this
> permission, but with that one".  I think that inheritance is the answer,
> because a macro requires you to know ahead of time that someone might be
> interested in making something similar.  I believe that Karl tried to
> start a discussion on inheritance a month ago, but there wasn't any
> interest.  Let's restart that discussion.  I think that whether through
> macros or inheritance, a rule to remove permissions is needed, because
> without one, we have to get the base classes or macros perfect.
>
>   

> 2) A way to export types in some manner that would still allow
> flexibility in renaming or splitting a type locally, without having to
> change the global name.  That global name would also have to be what
> shows up in audit logs and other things.  Maybe this is impossible and
> we are just stuck treating types as global entities.
>   

This relates to what I said earlier about completing the refpolicy 
abstractions by removing the global symbols. I'm not sure how well this 
can be done but I think its worth thinking about, if scoping symbols 
wasn't useful programming would be much different than it is today :)


--
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.

Re: Are the reference policy abstractions the right ones?

[Christopher J. PeBenito]

On Tue, 2007-10-09 at 11:08 -0400, James Carter wrote:
> I would like to start a discussion on whether reference policy is
> providing the right abstractions for writing policy.
> 
> This is not intended to be an attack on Chris or Dan, or their work.  I
> think that it is obvious that reference policy is much better organized,
> far more useful, and works way better than the old example policy.  We
> don't want to go back to example policy.
> 
> One of the goals of reference policy is to provide a more modern feel to
> the policy by eliminating the use of types in a global manner across the
> whole policy.  It does this by allowing interfaces to be defined through
> which permissions can be granted to the types of a module.  There seems
> to be several problems with this.
> 
> 1) The user is constantly presented with types.  They are in the audit
> logs, when the label of a process or file is displayed, and even in the
> man pages ("Set cgi scripts with httpd_sys_script_exec_t to allow them
> to run with access to all sys types.")

One thing that has been discussed is adding documentation for types.  I
suspect you're looking for something more than that.

> 2) We have traded needing to know about 2500 types or so to write
> policy, for needing to know around 4000 interfaces.  And no, I don't
> think that SELinux Clippy is the answer.

Well to be fair, about half of those interfaces are due to corenetwork.
At this point, I can't see a way to abstract most of corenetwork's
access, and we probably don't want to.  Its already at a level that most
admins understand, since they understand firewalls.

> 3) We don't need to abstract class and permissions, because they don't
> change very much, but frequently the interfaces consist of only a few
> allow rules.  Over 60% of the interfaces have only one line (not
> counting gen_require or refpolicywarn lines).
> Lines   # of Interfaces
>      0    53	These only have a refpolicywarn line
>      1  3080    Around 300 of these consist of a single dontaudit rule

I would expect that a large number of these are now implemented with
policy pattern macros.  As for the dontaudits, thats been problematic.
There definitely have been cases where a dontaudit has clearly come from
an enforcing machine.

For example, say a domain is reading a file, but it first stat()s it.
For whatever reason we want to dontaudit this.  On an enforcing system
we would just see the getattr denial since the program would probably
not try to open the file.  On a permissive system, we would get both
messages.  What we really want to do is dontaudit getattr and read, but
only a getattr dontaudit was written since we're on an enforcing system,
and never saw the read denial.  One example of this that comes to mind
is related to /proc/pid access.  Some might just dontaudit the directory
search, others might dontaudit that plus the read of the files.  I'd
like to fix things like this, but its not exactly easy to do without
auditing all dontaudits.

> I think that we need:
> 
> 1) A way to say, "I want a domain like that one, without this
> permission, but with that one".  I think that inheritance is the answer,
> because a macro requires you to know ahead of time that someone might be
> interested in making something similar.  I believe that Karl tried to
> start a discussion on inheritance a month ago, but there wasn't any
> interest.  Let's restart that discussion.  I think that whether through
> macros or inheritance, a rule to remove permissions is needed, because
> without one, we have to get the base classes or macros perfect.

I'm going to stay silent on this for the moment, I don't know how this
would work.

> 2) A way to export types in some manner that would still allow
> flexibility in renaming or splitting a type locally, without having to
> change the global name.  That global name would also have to be what
> shows up in audit logs and other things.  Maybe this is impossible and
> we are just stuck treating types as global entities.

In general, this is counter to refpolicy, as it would allow the access
for a module to be defined somewhere other than where the type is owned.
That being said, it may be acceptable in a very specific instance, where
you are directly calling a template defined in another module, and then
want to add on access to a type it creates.  An example would be at the
bottom of apcupsd.te, where an apache template is used and then access
is added onto some of the generated types, despite apcupsd not actually
knowing the name of the types created by the template.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



--
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.

Re: Are the reference policy abstractions the right ones?

[James Carter]

On Tue, 2007-10-09 at 13:10 -0400, Karl MacMillan wrote:
> On Tue, 2007-10-09 at 11:08 -0400, James Carter wrote:
> [...]
> > 
> > 1) A way to say, "I want a domain like that one, without this
> > permission, but with that one".  I think that inheritance is the answer,
> > because a macro requires you to know ahead of time that someone might be
> > interested in making something similar.  I believe that Karl tried to
> > start a discussion on inheritance a month ago, but there wasn't any
> > interest.  Let's restart that discussion.  I think that whether through
> > macros or inheritance, a rule to remove permissions is needed, because
> > without one, we have to get the base classes or macros perfect.
> > 
> 
> Like I said I think this would be useful.
> 
> > 2) A way to export types in some manner that would still allow
> > flexibility in renaming or splitting a type locally, without having to
> > change the global name.  That global name would also have to be what
> > shows up in audit logs and other things.  Maybe this is impossible and
> > we are just stuck treating types as global entities.
> > 
> 
> It occurs to me that removing the distinction between types and
> attributes and allowing nesting of them gets a lot of this. Say you have
> a type:
> 
> type foo;
> 
> allow foo etc_t : file read;
> allow foo self : process signal;
> 
> If you could then just say:
> 
> type bar, foo;
> 
> I.e., treat foo as an attribute. That would handle the type splitting
> issues for files as well. Nested attributes would also allow building up
> of more complex attributes:
> 
> attribute domain;
> # rules for a process
> 
> attribute daemon, domain;
> # daemon is also a domain. Add rules related
> # to being a daemon
> 
> attribute network_server, daemon;
> # A daemon that can talk on the network.

Still thinking about this, but why would you use the attribute
statement?

wouldn't it be this?

type domain
type daemon, domain
type network_server, daemon

-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency


--
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.

Re: Are the reference policy abstractions the right ones?

[Karl MacMillan]

On Tue, 2007-10-09 at 14:54 -0400, James Carter wrote:
> On Tue, 2007-10-09 at 13:10 -0400, Karl MacMillan wrote:
> > On Tue, 2007-10-09 at 11:08 -0400, James Carter wrote:
> > [...]
> > > 
> > > 1) A way to say, "I want a domain like that one, without this
> > > permission, but with that one".  I think that inheritance is the answer,
> > > because a macro requires you to know ahead of time that someone might be
> > > interested in making something similar.  I believe that Karl tried to
> > > start a discussion on inheritance a month ago, but there wasn't any
> > > interest.  Let's restart that discussion.  I think that whether through
> > > macros or inheritance, a rule to remove permissions is needed, because
> > > without one, we have to get the base classes or macros perfect.
> > > 
> > 
> > Like I said I think this would be useful.
> > 
> > > 2) A way to export types in some manner that would still allow
> > > flexibility in renaming or splitting a type locally, without having to
> > > change the global name.  That global name would also have to be what
> > > shows up in audit logs and other things.  Maybe this is impossible and
> > > we are just stuck treating types as global entities.
> > > 
> > 
> > It occurs to me that removing the distinction between types and
> > attributes and allowing nesting of them gets a lot of this. Say you have
> > a type:
> > 
> > type foo;
> > 
> > allow foo etc_t : file read;
> > allow foo self : process signal;
> > 
> > If you could then just say:
> > 
> > type bar, foo;
> > 
> > I.e., treat foo as an attribute. That would handle the type splitting
> > issues for files as well. Nested attributes would also allow building up
> > of more complex attributes:
> > 
> > attribute domain;
> > # rules for a process
> > 
> > attribute daemon, domain;
> > # daemon is also a domain. Add rules related
> > # to being a daemon
> > 
> > attribute network_server, daemon;
> > # A daemon that can talk on the network.
> 
> Still thinking about this,

That means that it is either brilliant or completely stupid :)

>  but why would you use the attribute
> statement?
> 
> wouldn't it be this?
> 
> type domain
> type daemon, domain
> type network_server, daemon
> 

Maybe - if we remove the distinction entirely. The only reason I can
think to leave the attribute statement is to mark a type as "abstract" -
i.e., can't actually be a label on a real subject or object in the
running system.

Karl


--
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.

Re: Are the reference policy abstractions the right ones?

[James Carter]

On Tue, 2007-10-09 at 15:07 -0400, Karl MacMillan wrote:
> On Tue, 2007-10-09 at 14:54 -0400, James Carter wrote:
> > On Tue, 2007-10-09 at 13:10 -0400, Karl MacMillan wrote:
> > > On Tue, 2007-10-09 at 11:08 -0400, James Carter wrote:
> > > [...]
> > > > 
> > > > 1) A way to say, "I want a domain like that one, without this
> > > > permission, but with that one".  I think that inheritance is the answer,
> > > > because a macro requires you to know ahead of time that someone might be
> > > > interested in making something similar.  I believe that Karl tried to
> > > > start a discussion on inheritance a month ago, but there wasn't any
> > > > interest.  Let's restart that discussion.  I think that whether through
> > > > macros or inheritance, a rule to remove permissions is needed, because
> > > > without one, we have to get the base classes or macros perfect.
> > > > 
> > > 
> > > Like I said I think this would be useful.
> > > 
> > > > 2) A way to export types in some manner that would still allow
> > > > flexibility in renaming or splitting a type locally, without having to
> > > > change the global name.  That global name would also have to be what
> > > > shows up in audit logs and other things.  Maybe this is impossible and
> > > > we are just stuck treating types as global entities.
> > > > 
> > > 
> > > It occurs to me that removing the distinction between types and
> > > attributes and allowing nesting of them gets a lot of this. Say you have
> > > a type:
> > > 
> > > type foo;
> > > 
> > > allow foo etc_t : file read;
> > > allow foo self : process signal;
> > > 
> > > If you could then just say:
> > > 
> > > type bar, foo;
> > > 
> > > I.e., treat foo as an attribute. That would handle the type splitting
> > > issues for files as well. Nested attributes would also allow building up
> > > of more complex attributes:
> > > 
> > > attribute domain;
> > > # rules for a process
> > > 
> > > attribute daemon, domain;
> > > # daemon is also a domain. Add rules related
> > > # to being a daemon
> > > 
> > > attribute network_server, daemon;
> > > # A daemon that can talk on the network.
> > 
> > Still thinking about this,
> 
> That means that it is either brilliant or completely stupid :)
> 
I guess that puts you in the company of string theorists. ;)

> >  but why would you use the attribute
> > statement?
> > 
> > wouldn't it be this?
> > 
> > type domain
> > type daemon, domain
> > type network_server, daemon
> > 
> 
> Maybe - if we remove the distinction entirely. The only reason I can
> think to leave the attribute statement is to mark a type as "abstract" -
> i.e., can't actually be a label on a real subject or object in the
> running system.
> 
There would be a few places where one might use an abstract type, domain
being one of them, but I am not sure they would be needed.

Your idea does seem to be simple, but it still won't handle the case
where there is type mangling.

if we have:

type foo;
allow foo foo_bar : file read;
type baz, foo;

Where foo_bar was created in some macro or interface.

It seems like baz would have read permission on foo_bar, when probably
we would like it to have read permission on baz_bar.

All of which you know and previously mentioned a month ago:
http://marc.info/?l=selinux&m=118961442411429&w=2

-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency


--
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.

Re: Are the reference policy abstractions the right ones?

[Karl MacMillan]

On Tue, 2007-10-09 at 15:44 -0400, James Carter wrote:
> On Tue, 2007-10-09 at 15:07 -0400, Karl MacMillan wrote:

[...]

> 
> > >  but why would you use the attribute
> > > statement?
> > > 
> > > wouldn't it be this?
> > > 
> > > type domain
> > > type daemon, domain
> > > type network_server, daemon
> > > 
> > 
> > Maybe - if we remove the distinction entirely. The only reason I can
> > think to leave the attribute statement is to mark a type as "abstract" -
> > i.e., can't actually be a label on a real subject or object in the
> > running system.
> > 
> There would be a few places where one might use an abstract type, domain
> being one of them, but I am not sure they would be needed.
> 
> Your idea does seem to be simple, but it still won't handle the case
> where there is type mangling.
> 
> if we have:
> 
> type foo;
> allow foo foo_bar : file read;
> type baz, foo;
> 
> Where foo_bar was created in some macro or interface.
> 
> It seems like baz would have read permission on foo_bar, when probably
> we would like it to have read permission on baz_bar.
> 
> All of which you know and previously mentioned a month ago:
> http://marc.info/?l=selinux&m=118961442411429&w=2
> 

Yeah - too bad I don't have an answer. We basically need a way to mark
groups of types as related and do self-like replacements. No good syntax
suggestions here.

Karl


--
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.

Re: Are the reference policy abstractions the right ones?

[Karl MacMillan]

On Tue, 2007-10-09 at 11:08 -0400, James Carter wrote:
> I would like to start a discussion on whether reference policy is
> providing the right abstractions for writing policy.
> 
> This is not intended to be an attack on Chris or Dan, or their work.  I
> think that it is obvious that reference policy is much better organized,
> far more useful, and works way better than the old example policy.  We
> don't want to go back to example policy.
> 
> One of the goals of reference policy is to provide a more modern feel to
> the policy by eliminating the use of types in a global manner across the
> whole policy.  It does this by allowing interfaces to be defined through
> which permissions can be granted to the types of a module.  There seems
> to be several problems with this.
> 

Let me ask a different question. Both the old example policy and the
reference policy accomplish the same basic thing: comprehensive
least-privilege. The challenge with this approach is that the policy is
closely tied to applications and brittle in the face of application
changes.

So - are there other useful approaches that we could take? Some modified
form of integrity policies like BIBA? Perhaps just for portions of the
policy - things like hal/udev that are basically in the TCB but need to
be protected from applications.

Seems like a long-shot, but I thought I would ask.

Karl


--
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.

Re: Are the reference policy abstractions the right ones?

[Karl MacMillan]

On Tue, 2007-10-09 at 16:00 -0400, Karl MacMillan wrote:
> On Tue, 2007-10-09 at 15:44 -0400, James Carter wrote:
> > On Tue, 2007-10-09 at 15:07 -0400, Karl MacMillan wrote:
> 
> [...]
> 
> > 
> > > >  but why would you use the attribute
> > > > statement?
> > > > 
> > > > wouldn't it be this?
> > > > 
> > > > type domain
> > > > type daemon, domain
> > > > type network_server, daemon
> > > > 
> > > 
> > > Maybe - if we remove the distinction entirely. The only reason I can
> > > think to leave the attribute statement is to mark a type as "abstract" -
> > > i.e., can't actually be a label on a real subject or object in the
> > > running system.
> > > 
> > There would be a few places where one might use an abstract type, domain
> > being one of them, but I am not sure they would be needed.
> > 
> > Your idea does seem to be simple, but it still won't handle the case
> > where there is type mangling.
> > 
> > if we have:
> > 
> > type foo;
> > allow foo foo_bar : file read;
> > type baz, foo;
> > 
> > Where foo_bar was created in some macro or interface.
> > 
> > It seems like baz would have read permission on foo_bar, when probably
> > we would like it to have read permission on baz_bar.
> > 
> > All of which you know and previously mentioned a month ago:
> > http://marc.info/?l=selinux&m=118961442411429&w=2
> > 
> 
> Yeah - too bad I don't have an answer. We basically need a way to mark
> groups of types as related and do self-like replacements. No good syntax
> suggestions here.
> 

Here's a suggestion (this assumes that hierarchy stops using dot in
favor of explicit statements):

type_group daemon {
	type process, domain;
	type exec, exec_file;
	type conf, file_type;
	type log, log_file;
}

allow daemon.process daemon.exec : file entrypoint;
# etc., etc. for the exec permissions - could
# even have a type_transition.
allow daemon.process daemon.conf : file read;
allow daemon.process daemon.log : file { read write };

# Apache gets all of the types defined in daemon and
# access to the apache versions - so apache.process
# can read apache.conf.
type_group apache, daemon {
	type html_files, file;
}

allow apache.process apache.html_files : file read;

This handles the new set of types that is separate from the existing
set. We could also make some of the groups "abstract" - so that
daemon.process can't be applied to a process.

To handle the need for extension - Dan's java_t example. Assuming we
have unconfined, wouldn't this work:

type java_t, unconfined_t;

allow java_t self : process execmem;

Karl


--
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.

Re: Are the reference policy abstractions the right ones?

[Joshua Brindle]

Karl MacMillan wrote:
> On Tue, 2007-10-09 at 16:00 -0400, Karl MacMillan wrote:
>   
>> On Tue, 2007-10-09 at 15:44 -0400, James Carter wrote:
>>     
>>> On Tue, 2007-10-09 at 15:07 -0400, Karl MacMillan wrote:
>>>       
>> [...]
>>
>>     
>>>>>  but why would you use the attribute
>>>>> statement?
>>>>>
>>>>> wouldn't it be this?
>>>>>
>>>>> type domain
>>>>> type daemon, domain
>>>>> type network_server, daemon
>>>>>
>>>>>           
>>>> Maybe - if we remove the distinction entirely. The only reason I can
>>>> think to leave the attribute statement is to mark a type as "abstract" -
>>>> i.e., can't actually be a label on a real subject or object in the
>>>> running system.
>>>>
>>>>         
>>> There would be a few places where one might use an abstract type, domain
>>> being one of them, but I am not sure they would be needed.
>>>
>>> Your idea does seem to be simple, but it still won't handle the case
>>> where there is type mangling.
>>>
>>> if we have:
>>>
>>> type foo;
>>> allow foo foo_bar : file read;
>>> type baz, foo;
>>>
>>> Where foo_bar was created in some macro or interface.
>>>
>>> It seems like baz would have read permission on foo_bar, when probably
>>> we would like it to have read permission on baz_bar.
>>>
>>> All of which you know and previously mentioned a month ago:
>>> http://marc.info/?l=selinux&m=118961442411429&w=2
>>>
>>>       
>> Yeah - too bad I don't have an answer. We basically need a way to mark
>> groups of types as related and do self-like replacements. No good syntax
>> suggestions here.
>>
>>     
>
> Here's a suggestion (this assumes that hierarchy stops using dot in
> favor of explicit statements):
>
> type_group daemon {
> 	type process, domain;
> 	type exec, exec_file;
> 	type conf, file_type;
> 	type log, log_file;
> }
>
> allow daemon.process daemon.exec : file entrypoint;
> # etc., etc. for the exec permissions - could
> # even have a type_transition.
> allow daemon.process daemon.conf : file read;
> allow daemon.process daemon.log : file { read write };
>
> # Apache gets all of the types defined in daemon and
> # access to the apache versions - so apache.process
> # can read apache.conf.
> type_group apache, daemon {
> 	type html_files, file;
> }
>
> allow apache.process apache.html_files : file read;
>
> This handles the new set of types that is separate from the existing
> set. We could also make some of the groups "abstract" - so that
> daemon.process can't be applied to a process.
>
>   

Interesting, as we were talking about in IRC it might be an interesting 
idea to graphically export a 'reduce granularity' slider to make things 
very easy to reduce the strictness of a policy on a particular 
application (group of domains). With the dots if the hierarchy is still 
used you can just remove domains and file types at higher levels of 
granularity (more dots). I don't know, maybe a really bad idea but it 
seems like an interesting way to reduce the granularity of policy 
enforcement in an automated and easily accessible way.


> To handle the need for extension - Dan's java_t example. Assuming we
> have unconfined, wouldn't this work:
>
> type java_t, unconfined_t;
>
> allow java_t self : process execmem;
>   





--
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.

Re: Are the reference policy abstractions the right ones?

[Casey Schaufler]

--- Karl MacMillan <kmacmillan@mentalrootkit.com> wrote:


> Let me ask a different question. Both the old example policy and the
> reference policy accomplish the same basic thing: comprehensive
> least-privilege. The challenge with this approach is that the policy is
> closely tied to applications and brittle in the face of application
> changes.
> 
> So - are there other useful approaches that we could take? Some modified
> form of integrity policies like BIBA?

Biba (It's a name, not an acronym) has been used to effect in other
systems. Since you already have Bell&LaPadula implemented adding
Bida should be the work of an afternoon. We found that in real world
use it degenerated to a binary integrity policy pretty quickly, with
system integrity and user integrity being the only values that actually
got used. There appear to be more granularity advocates about these
days, however, so it might prove useful.

> Perhaps just for portions of the
> policy - things like hal/udev that are basically in the TCB but need to
> be protected from applications.

Explicitly and directly protecting the TCB is a good thing in
my view, although I think that it runs a bit counter to the TE
philosophy.

> Seems like a long-shot, but I thought I would ask.

A Biba integrity component, like a Bell & Lapadula sensitivity
component, ought not to be strictly necessary in a TE system. The
grand promise of TE is that such schemes are unnecessary with the
proper definition of domains. I think that the current introspection
on the policy abstraction is very well founded and that the
observations being made should be taken seriously.

I have long been of the opinion that the policy should be designed
and the applications fit into the policy rather than accepting the
behavior of applications as proper and crafting a policy that allows
for that behavior. It's the same distinction as creating a test suite
from a specification and redirecting a program's output into a file
and calling that the reference results. We can quibble about the 
degree to which each approach has been used on any given program
or subsystem, but I don't think anyone would claim the the reference
policy has an overall design. I didn't find one on the Tresys site.



Casey Schaufler
casey@schaufler-ca.com

--
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.

Re: Are the reference policy abstractions the right ones?

[James Carter]

On Wed, 2007-10-10 at 11:23 -0400, Karl MacMillan wrote:
[...]
> 
> Here's a suggestion (this assumes that hierarchy stops using dot in
> favor of explicit statements):
> 
> type_group daemon {
> 	type process, domain;
> 	type exec, exec_file;
> 	type conf, file_type;
> 	type log, log_file;
> }
> 

Why not call it type_class?

> allow daemon.process daemon.exec : file entrypoint;
> # etc., etc. for the exec permissions - could
> # even have a type_transition.
> allow daemon.process daemon.conf : file read;
> allow daemon.process daemon.log : file { read write };
> 
So, process, exec, conf, and log are in scope within the type_group
block and are referred to outside of that block by identifying the
namespace using a ".".  Sort of like referring to functions in a python
module.  Is that right?

> # Apache gets all of the types defined in daemon and
> # access to the apache versions - so apache.process
> # can read apache.conf.
> type_group apache, daemon {
> 	type html_files, file;
> }
> 
> allow apache.process apache.html_files : file read;
> 

Would there be allow rules inside the type_group block?  I think that it
would be needed to distinguish between rules that can be inherited or
not.

For example,

type_group daemon {
	type process, domain;

	allow process foo_t : file read;
}
allow daemon.process bar_t : file read;

type_group apache, daemon {
	...
}

apache.process would not have read access on bar_t, but it would on
foo_t.


Multiple inheritance would be possible, but tricky.

If the following was also defined:

type_group b {
	type context;
	type process;
	...
}

type_group c, b, daemon {
	type process;
	...
}

What rules would c.process have?  Maybe a union of all the rules for
process?  Maybe the namespacing should look like c.process, c.b.process,
and c.daemon.process?

If namsepacing worked in the later way, it could provide some useful
information. if I see denials on a.daemon.log, b.daemon.log, and
c.daemon.log, I have an idea where the problem is.  On the other hand,
it could look pretty ugly: a.b.c.d.e.f.g.daemon.log.  Maybe type aliases
could help with the ugliness though.  You also might be able to use type
aliases to define both c.b.process and c.daemon.process to be c_process
and have a union of the permissions.

We still need a way to deny or disallow permissions.  It also might be
useful to remove types.

So, using the type_group daemon that you defined:

type_group d, daemon {
	remove_type daemon.conf;
	remove_type daemon.log;

	disallow daemon.process blah : file read;
}

I don't know; maybe I am the crazy one.

> This handles the new set of types that is separate from the existing
> set. We could also make some of the groups "abstract" - so that
> daemon.process can't be applied to a process.
> 
> To handle the need for extension - Dan's java_t example. Assuming we
> have unconfined, wouldn't this work:
> 
> type java_t, unconfined_t;
> 
> allow java_t self : process execmem;
> 
> Karl
> 
> 
> --
> 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.
-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency


--
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.

Re: Are the reference policy abstractions the right ones?

[Paul Moore]

On Wednesday 10 October 2007 11:09:59 am Karl MacMillan wrote:
> Let me ask a different question. Both the old example policy and the
> reference policy accomplish the same basic thing: comprehensive
> least-privilege. The challenge with this approach is that the policy is
> closely tied to applications and brittle in the face of application
> changes.
>
> So - are there other useful approaches that we could take? Some modified
> form of integrity policies like BIBA? Perhaps just for portions of the
> policy - things like hal/udev that are basically in the TCB but need to
> be protected from applications.
>
> Seems like a long-shot, but I thought I would ask.

I definitely think it's a valid question, and one that I think is worth 
pondering for a little bit.  One of the greatest strengths of SELinux, in my 
opinion, is it's decoupling of policy from enforcement.  We have the ability 
to offer many different types of policies yet we continue to focus on one 
common policy source.  While the reference policy does provide the ability to 
provide different variations, they are still rooted in the idea 
of "comprehensive least-privilege".  

The reference policy is a huge improvement over the old example policy, but 
I'm not convinced that it is the "everything to everyone" policy.  I think 
adopting the founding concepts of the reference policy (modularity, 
abstractions, etc.) and using these concept to start looking at alternative 
approaches to SELinux policy (in parallel to refpolicy) as Karl suggested 
would be a worthwhile exercise.

-- 
paul moore
linux security @ hp

--
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.

Re: Are the reference policy abstractions the right ones?

[Karl MacMillan]

On Wed, 2007-10-10 at 12:52 -0400, James Carter wrote:
> On Wed, 2007-10-10 at 11:23 -0400, Karl MacMillan wrote:
> [...]
> > 
> > Here's a suggestion (this assumes that hierarchy stops using dot in
> > favor of explicit statements):
> > 
> > type_group daemon {
> > 	type process, domain;
> > 	type exec, exec_file;
> > 	type conf, file_type;
> > 	type log, log_file;
> > }
> > 
> 
> Why not call it type_class?

Or type_struct :) I don't really care . . .

> 
> > allow daemon.process daemon.exec : file entrypoint;
> > # etc., etc. for the exec permissions - could
> > # even have a type_transition.
> > allow daemon.process daemon.conf : file read;
> > allow daemon.process daemon.log : file { read write };
> > 
> So, process, exec, conf, and log are in scope within the type_group
> block and are referred to outside of that block by identifying the
> namespace using a ".".  Sort of like referring to functions in a python
> module.  Is that right?
> 

Yep.

> > # Apache gets all of the types defined in daemon and
> > # access to the apache versions - so apache.process
> > # can read apache.conf.
> > type_group apache, daemon {
> > 	type html_files, file;
> > }
> > 
> > allow apache.process apache.html_files : file read;
> > 
> 
> Would there be allow rules inside the type_group block?  I think that it
> would be needed to distinguish between rules that can be inherited or
> not.
> 
> For example,
> 
> type_group daemon {
> 	type process, domain;
> 
> 	allow process foo_t : file read;
> }
> allow daemon.process bar_t : file read;
> 
> type_group apache, daemon {
> 	...
> }
> 
> apache.process would not have read access on bar_t, but it would on
> foo_t.
> 

That's interesting - I'm having trouble thinking of useful examples
though. And it would need to allow you to add rules "inside" outside of
the original declaration.

> 
> Multiple inheritance would be possible, but tricky.
> 
> If the following was also defined:
> 
> type_group b {
> 	type context;
> 	type process;
> 	...
> }
> 
> type_group c, b, daemon {
> 	type process;
> 	...
> }
> 
> What rules would c.process have?  Maybe a union of all the rules for
> process?

That's actually kind of interesting. The union would allow some
interesting customization:

type_group writable_conf {
	type process;
	type conf;
}

allow writable_conf.process writable_conf.conf : file write;

# add to an existing group
type_group apache, writable_conf;

If we ended up with standard names it would be pretty nice.

>   Maybe the namespacing should look like c.process, c.b.process,
> and c.daemon.process?
> 
> If namsepacing worked in the later way, it could provide some useful
> information. if I see denials on a.daemon.log, b.daemon.log, and
> c.daemon.log, I have an idea where the problem is.  On the other hand,
> it could look pretty ugly: a.b.c.d.e.f.g.daemon.log.  Maybe type aliases
> could help with the ugliness though.  You also might be able to use type
> aliases to define both c.b.process and c.daemon.process to be c_process
> and have a union of the permissions.
> 

Wow - that kind of makes my head explode.

> We still need a way to deny or disallow permissions.  It also might be
> useful to remove types.
> 
> So, using the type_group daemon that you defined:
> 
> type_group d, daemon {
> 	remove_type daemon.conf;
> 	remove_type daemon.log;
> 
> 	disallow daemon.process blah : file read;
> }
> 
> I don't know; maybe I am the crazy one.
> 

Seriously - though excluding types is not a bad idea. What about

type_group d, daemon {
	except type daemon.conf;
}

And that might be really useful with multiple inheritance.

Karl


--
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.

RE: Are the reference policy abstractions the right ones?

[Frank L. Mayer]

> One of the goals of reference policy is to provide a more modern feel to
> the policy by eliminating the use of types in a global manner across the
> whole policy.  It does this by allowing interfaces to be defined through
> which permissions can be granted to the types of a module.  There seems
> to be several problems with this.
 
Probably the primary motivation for this and other refpol goals was to allow tool manipulation of source policies and the creation of development tools and higher-level/domain-specific languages. Chris can talk better about the challenges with the implementation  (such as the weakness of m4 as an implementation language), but perhaps our real failure is not creating better higher level abstractions/languages/tools upoon the re-structured "assembly" policy language. 
 
> 1) The user is constantly presented with types. 
 
Which is perhaps the problem for simplication of development/admin. All I know is that it was impossible to create any type of policy source tools/domain-specific languages when types were gloablly used throughout the sources. Not that I have any concrete suggestions how to improve the situation off hand ;)
 
Frank

 


--
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.

Re: Are the reference policy abstractions the right ones?

[Karl MacMillan]

On Wed, 2007-10-10 at 16:39 -0400, Karl MacMillan wrote:
> On Wed, 2007-10-10 at 12:52 -0400, James Carter wrote:
> > On Wed, 2007-10-10 at 11:23 -0400, Karl MacMillan wrote:
> > [...]
> > > 
> > > Here's a suggestion (this assumes that hierarchy stops using dot in
> > > favor of explicit statements):
> > > 
> > > type_group daemon {
> > > 	type process, domain;
> > > 	type exec, exec_file;
> > > 	type conf, file_type;
> > > 	type log, log_file;
> > > }
> > > 
> > 
> > Why not call it type_class?
> 
> Or type_struct :) I don't really care . . .
> 
> > 
> > > allow daemon.process daemon.exec : file entrypoint;
> > > # etc., etc. for the exec permissions - could
> > > # even have a type_transition.
> > > allow daemon.process daemon.conf : file read;
> > > allow daemon.process daemon.log : file { read write };
> > > 
> > So, process, exec, conf, and log are in scope within the type_group
> > block and are referred to outside of that block by identifying the
> > namespace using a ".".  Sort of like referring to functions in a python
> > module.  Is that right?
> > 
> 
> Yep.
> 
> > > # Apache gets all of the types defined in daemon and
> > > # access to the apache versions - so apache.process
> > > # can read apache.conf.
> > > type_group apache, daemon {
> > > 	type html_files, file;
> > > }
> > > 
> > > allow apache.process apache.html_files : file read;
> > > 
> > 
> > Would there be allow rules inside the type_group block?  I think that it
> > would be needed to distinguish between rules that can be inherited or
> > not.
> > 
> > For example,
> > 
> > type_group daemon {
> > 	type process, domain;
> > 
> > 	allow process foo_t : file read;
> > }
> > allow daemon.process bar_t : file read;
> > 
> > type_group apache, daemon {
> > 	...
> > }
> > 
> > apache.process would not have read access on bar_t, but it would on
> > foo_t.
> > 
> 
> That's interesting - I'm having trouble thinking of useful examples
> though. And it would need to allow you to add rules "inside" outside of
> the original declaration.
> 

Thinking about this more - this is actually the same mistake we have
already made. Our whole model is that the flexibility has to be
anticipated by the policy author ahead of time. Say I create a firefox
policy and later some admin wants create a different firefox policy
based on that (that, say, limits connections to only the intranet, or
prevents writing to the home directory, etc.). Currently the policy
author must:

a) make the whole policy into a template
b) factor out all of the access that the later author may want to
exclude.

It is killing us. So I think we need a way to exclude rules on
inheritance. For example:

type_group firefox {
	type process, domain;
	type conf, conf_file;
}

# bunch of rules, including reading user home dirs and
# connect / send / receive anywhere

type_group intranet_firefox {
	except process user_home_t : file all_file_perms;
	# also exclude network
}

# allow limited network access

No idea about that syntax - they idea is to prevent access from being
inherited. These are not deny rules - they only limit inheritance. I
think this solves a lot of problems with deny rules - there is no
ordering, precedence, or any related problems.

It also gives the flexibility that we have been needing. I also think we
should make it easy to except lots of access (e.g., except all access on
sockets or all access to a source type). This will make the exception
more robust.

So - I'd like to hear from some other people. Are these ideas worth
pursuing? The proposals:

1) remove the distinction between attributes / types.
2) allow nested types / attributes.
3) type_class / type_group
4) exceptions

Karl






--
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.

Re: Are the reference policy abstractions the right ones?

[James Carter]

On Thu, 2007-10-11 at 13:00 -0400, Karl MacMillan wrote:
> On Wed, 2007-10-10 at 16:39 -0400, Karl MacMillan wrote:
> > On Wed, 2007-10-10 at 12:52 -0400, James Carter wrote:
> > > On Wed, 2007-10-10 at 11:23 -0400, Karl MacMillan wrote:
> > > [...]
> > > > 
> > > > Here's a suggestion (this assumes that hierarchy stops using dot in
> > > > favor of explicit statements):
> > > > 
> > > > type_group daemon {
> > > > 	type process, domain;
> > > > 	type exec, exec_file;
> > > > 	type conf, file_type;
> > > > 	type log, log_file;
> > > > }
> > > > 
> > > 
> > > Why not call it type_class?
> > 
> > Or type_struct :) I don't really care . . .
> > 
> > > 
> > > > allow daemon.process daemon.exec : file entrypoint;
> > > > # etc., etc. for the exec permissions - could
> > > > # even have a type_transition.
> > > > allow daemon.process daemon.conf : file read;
> > > > allow daemon.process daemon.log : file { read write };
> > > > 
> > > So, process, exec, conf, and log are in scope within the type_group
> > > block and are referred to outside of that block by identifying the
> > > namespace using a ".".  Sort of like referring to functions in a python
> > > module.  Is that right?
> > > 
> > 
> > Yep.
> > 
> > > > # Apache gets all of the types defined in daemon and
> > > > # access to the apache versions - so apache.process
> > > > # can read apache.conf.
> > > > type_group apache, daemon {
> > > > 	type html_files, file;
> > > > }
> > > > 
> > > > allow apache.process apache.html_files : file read;
> > > > 
> > > 
> > > Would there be allow rules inside the type_group block?  I think that it
> > > would be needed to distinguish between rules that can be inherited or
> > > not.
> > > 
> > > For example,
> > > 
> > > type_group daemon {
> > > 	type process, domain;
> > > 
> > > 	allow process foo_t : file read;
> > > }
> > > allow daemon.process bar_t : file read;
> > > 
> > > type_group apache, daemon {
> > > 	...
> > > }
> > > 
> > > apache.process would not have read access on bar_t, but it would on
> > > foo_t.
> > > 
> > 
> > That's interesting - I'm having trouble thinking of useful examples
> > though. And it would need to allow you to add rules "inside" outside of
> > the original declaration.
> > 
> 
I can't think of any examples where it would be useful either.  It just
seemed like there should be a way to distinguish between the rules that
should be inherited and those that shouldn't.  I think that you have the
right idea below.  The except rule would allow the type_group doing the
inheriting to make the decision, which is the right way of doing it.

> Thinking about this more - this is actually the same mistake we have
> already made. Our whole model is that the flexibility has to be
> anticipated by the policy author ahead of time. Say I create a firefox
> policy and later some admin wants create a different firefox policy
> based on that (that, say, limits connections to only the intranet, or
> prevents writing to the home directory, etc.). Currently the policy
> author must:
> 
> a) make the whole policy into a template
> b) factor out all of the access that the later author may want to
> exclude.
> 
> It is killing us. So I think we need a way to exclude rules on
> inheritance. For example:
> 
> type_group firefox {
> 	type process, domain;
> 	type conf, conf_file;
> }
> 
> # bunch of rules, including reading user home dirs and
> # connect / send / receive anywhere
> 
> type_group intranet_firefox {
> 	except process user_home_t : file all_file_perms;
> 	# also exclude network
> }
> 
This looks good to me.  If all permissions are excluded, then that type
is essentially not inherited.

Would you be able to do this?
allow firefox foo_t : file read;

If you can, then why not get rid of the distinction between types and
type_groups?  ;)  I mean, other then the fact that it hurts to think
about nested type_groups inheriting other nested type_groups and that it
would probably add little value for a lot of complexity.

> # allow limited network access
> 
> No idea about that syntax - they idea is to prevent access from being
> inherited. These are not deny rules - they only limit inheritance. I
> think this solves a lot of problems with deny rules - there is no
> ordering, precedence, or any related problems.
> 
> It also gives the flexibility that we have been needing. I also think we
> should make it easy to except lots of access (e.g., except all access on
> sockets or all access to a source type). This will make the exception
> more robust.
> 
> So - I'd like to hear from some other people. Are these ideas worth
> pursuing? The proposals:
> 
> 1) remove the distinction between attributes / types.
> 2) allow nested types / attributes.
> 3) type_class / type_group
> 4) exceptions

I think that these are all interesting ideas.

> 
> Karl
> 
> 
> 
> 
-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency


--
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.

RE: Are the reference policy abstractions the right ones?

[James Carter]

On Thu, 2007-10-11 at 03:18 -0400, Frank L. Mayer wrote:
> > One of the goals of reference policy is to provide a more modern feel to
> > the policy by eliminating the use of types in a global manner across the
> > whole policy.  It does this by allowing interfaces to be defined through
> > which permissions can be granted to the types of a module.  There seems
> > to be several problems with this.
>  
> Probably the primary motivation for this and other refpol goals was to allow tool manipulation of source policies and the creation of development tools and higher-level/domain-specific languages. Chris can talk better about the challenges with the implementation  (such as the weakness of m4 as an implementation language), but perhaps our real failure is not creating better higher level abstractions/languages/tools upoon the re-structured "assembly" policy language. 
 
The difficulty with trying to build a higher-level language on top of
policy language is that, unlike a program that is being executed, there
is no locality in the policy.  When a problem occurs while a program is
executing, you can get a stack trace and see what functions were
executing.  When there is a denial in policy, all you know is that that
rule does not exist.  There is no way to say where that rule would have
been if it had existed.  This makes it very hard to abstract away that
lower level language.

> > 1) The user is constantly presented with types. 
>  
> Which is perhaps the problem for simplication of development/admin. All I know is that it was impossible to create any type of policy source tools/domain-specific languages when types were gloablly used throughout the sources. Not that I have any concrete suggestions how to improve the situation off hand ;)
>  
> Frank
> 
>  
> 
> 
> --
> 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.
-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency


--
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.

Re: Are the reference policy abstractions the right ones?

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Karl MacMillan wrote:
> On Tue, 2007-10-09 at 16:00 -0400, Karl MacMillan wrote:
>> On Tue, 2007-10-09 at 15:44 -0400, James Carter wrote:
>>> On Tue, 2007-10-09 at 15:07 -0400, Karl MacMillan wrote:
>> [...]
>>
>>>>>  but why would you use the attribute
>>>>> statement?
>>>>>
>>>>> wouldn't it be this?
>>>>>
>>>>> type domain
>>>>> type daemon, domain
>>>>> type network_server, daemon
>>>>>
>>>> Maybe - if we remove the distinction entirely. The only reason I can
>>>> think to leave the attribute statement is to mark a type as "abstract" -
>>>> i.e., can't actually be a label on a real subject or object in the
>>>> running system.
>>>>
>>> There would be a few places where one might use an abstract type, domain
>>> being one of them, but I am not sure they would be needed.
>>>
>>> Your idea does seem to be simple, but it still won't handle the case
>>> where there is type mangling.
>>>
>>> if we have:
>>>
>>> type foo;
>>> allow foo foo_bar : file read;
>>> type baz, foo;
>>>
>>> Where foo_bar was created in some macro or interface.
>>>
>>> It seems like baz would have read permission on foo_bar, when probably
>>> we would like it to have read permission on baz_bar.
>>>
>>> All of which you know and previously mentioned a month ago:
>>> http://marc.info/?l=selinux&m=118961442411429&w=2
>>>
>> Yeah - too bad I don't have an answer. We basically need a way to mark
>> groups of types as related and do self-like replacements. No good syntax
>> suggestions here.
>>
> 
> Here's a suggestion (this assumes that hierarchy stops using dot in
> favor of explicit statements):
> 
> type_group daemon {
> 	type process, domain;
> 	type exec, exec_file;
> 	type conf, file_type;
> 	type log, log_file;
> }
> 
> allow daemon.process daemon.exec : file entrypoint;
> # etc., etc. for the exec permissions - could
> # even have a type_transition.
> allow daemon.process daemon.conf : file read;
> allow daemon.process daemon.log : file { read write };
> 
> # Apache gets all of the types defined in daemon and
> # access to the apache versions - so apache.process
> # can read apache.conf.
> type_group apache, daemon {
> 	type html_files, file;
> }
> 
> allow apache.process apache.html_files : file read;
> 
> This handles the new set of types that is separate from the existing
> set. We could also make some of the groups "abstract" - so that
> daemon.process can't be applied to a process.
> 
> To handle the need for extension - Dan's java_t example. Assuming we
> have unconfined, wouldn't this work:
> 
> type java_t, unconfined_t;
> 
> allow java_t self : process execmem;
> 
> Karl
> 
> 
> --
> 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.

I love the idea of inheritance and bringing the idea of OO to policy
writing.  A lot of the policy we write now is cookie cutter, and
system-config-selinux/poligygentool is attempting to create as much of
this reference policy as possible.   We should be able to easily
generate most of the policy out of a few basic types.  My tool currently
 defines four types of applications  and two types of users/roles.

All the interfaces for a new type should be created automatically based
on the type.  So if I create a file_type.  You get getattr, read , rw,
manage.  If the file type is defined as a var_lib, you automatically get
the transition from var_lib to domain_var_lib.




Ok a couple of hard questions.

My java_t example, requires all of the same permissions as unconfined_t
including if java_t creates a file in /tmp, it gets created as
unconfined_tmp_t not java_tmp_t.

But other situations if I create a

type webmail_t, http_sys_script_t.

I want total separation.


So one relations ship is a exend and the second one is a duplicate.

java_t extends unconfined_t only adding java_exec_t

while webmail_t would need all the types associated with the
http_sys_script_t

The tools should generate all of the "interfaces automatically.  So
If I want to show the relationship between two domains.

system_dbus_t.transition(networkmanager_t)

system_dbus_t.signal(network_manager_t)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHDrIUrlYvE4MpobMRAjriAKDjW5myjwZRKXtL4z5SgH90IRSYZgCcCnK7
Cqk6kg0uVLgAa8a1+Xl/qVc=
=4QaF
-----END PGP SIGNATURE-----

--
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.

Re: Are the reference policy abstractions the right ones?

[Chad Sellers]

On 10/11/07 1:00 PM, "Karl MacMillan" <kmacmillan@mentalrootkit.com> wrote:

> On Wed, 2007-10-10 at 16:39 -0400, Karl MacMillan wrote:
>> On Wed, 2007-10-10 at 12:52 -0400, James Carter wrote:
>>> On Wed, 2007-10-10 at 11:23 -0400, Karl MacMillan wrote:
>>> [...]
>>>> 
>>>> Here's a suggestion (this assumes that hierarchy stops using dot in
>>>> favor of explicit statements):
>>>> 
>>>> type_group daemon {
>>>> type process, domain;
>>>> type exec, exec_file;
>>>> type conf, file_type;
>>>> type log, log_file;
>>>> }
>>>> 
>>> 
>>> Why not call it type_class?
>> 
>> Or type_struct :) I don't really care . . .
>> 
>>> 
>>>> allow daemon.process daemon.exec : file entrypoint;
>>>> # etc., etc. for the exec permissions - could
>>>> # even have a type_transition.
>>>> allow daemon.process daemon.conf : file read;
>>>> allow daemon.process daemon.log : file { read write };
>>>> 
>>> So, process, exec, conf, and log are in scope within the type_group
>>> block and are referred to outside of that block by identifying the
>>> namespace using a ".".  Sort of like referring to functions in a python
>>> module.  Is that right?
>>> 
>> 
>> Yep.
>> 
>>>> # Apache gets all of the types defined in daemon and
>>>> # access to the apache versions - so apache.process
>>>> # can read apache.conf.
>>>> type_group apache, daemon {
>>>> type html_files, file;
>>>> }
>>>> 
>>>> allow apache.process apache.html_files : file read;
>>>> 
>>> 
>>> Would there be allow rules inside the type_group block?  I think that it
>>> would be needed to distinguish between rules that can be inherited or
>>> not.
>>> 
>>> For example,
>>> 
>>> type_group daemon {
>>> type process, domain;
>>> 
>>> allow process foo_t : file read;
>>> }
>>> allow daemon.process bar_t : file read;
>>> 
>>> type_group apache, daemon {
>>> ...
>>> }
>>> 
>>> apache.process would not have read access on bar_t, but it would on
>>> foo_t.
>>> 
>> 
>> That's interesting - I'm having trouble thinking of useful examples
>> though. And it would need to allow you to add rules "inside" outside of
>> the original declaration.
>> 
> 
> Thinking about this more - this is actually the same mistake we have
> already made. Our whole model is that the flexibility has to be
> anticipated by the policy author ahead of time. Say I create a firefox
> policy and later some admin wants create a different firefox policy
> based on that (that, say, limits connections to only the intranet, or
> prevents writing to the home directory, etc.). Currently the policy
> author must:
> 
> a) make the whole policy into a template
> b) factor out all of the access that the later author may want to
> exclude.
> 
> It is killing us. So I think we need a way to exclude rules on
> inheritance. For example:
> 
> type_group firefox {
> type process, domain;
> type conf, conf_file;
> }
> 
> # bunch of rules, including reading user home dirs and
> # connect / send / receive anywhere
> 
> type_group intranet_firefox {
> except process user_home_t : file all_file_perms;
> # also exclude network
> }
> 
> # allow limited network access
> 
> No idea about that syntax - they idea is to prevent access from being
> inherited. These are not deny rules - they only limit inheritance. I
> think this solves a lot of problems with deny rules - there is no
> ordering, precedence, or any related problems.
> 
> It also gives the flexibility that we have been needing. I also think we
> should make it easy to except lots of access (e.g., except all access on
> sockets or all access to a source type). This will make the exception
> more robust.
> 
> So - I'd like to hear from some other people. Are these ideas worth
> pursuing? The proposals:
> 
> 1) remove the distinction between attributes / types.
> 2) allow nested types / attributes.
> 3) type_class / type_group
> 4) exceptions
> 
I think these are all very nice features that could definitely come in
handy. But I'm not sure I see how they address our fundamental problems. I
agree with you guys that our fundamental problem is the leaky abstractions
in reference policy. I really don't see how these would solve that problem,
unless you're proposing that these would negate the need for any
abstractions. And I don't think that's what you're saying (or is it?).

Assuming this is a separate part of the conversation geared toward solving
other problems (not the leaky abstraction problem), then there are some
pretty cool features here. type_group is essentially a language
implementation of reference policy templates, so I'd love to see something
like it. Adding exceptions overcomes one of the main problems with templates
currently. 

Chad

> Karl
> 
> 
> 
> 
> 
> 
> --
> 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.


--
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.

Re: Are the reference policy abstractions the right ones?

[Chad Sellers]

On 10/11/07 4:26 PM, "James Carter" <jwcart2@tycho.nsa.gov> wrote:

> On Thu, 2007-10-11 at 03:18 -0400, Frank L. Mayer wrote:
>>> One of the goals of reference policy is to provide a more modern feel to
>>> the policy by eliminating the use of types in a global manner across the
>>> whole policy.  It does this by allowing interfaces to be defined through
>>> which permissions can be granted to the types of a module.  There seems
>>> to be several problems with this.
>>  
>> Probably the primary motivation for this and other refpol goals was to allow
>> tool manipulation of source policies and the creation of development tools
>> and higher-level/domain-specific languages. Chris can talk better about the
>> challenges with the implementation  (such as the weakness of m4 as an
>> implementation language), but perhaps our real failure is not creating better
>> higher level abstractions/languages/tools upoon the re-structured "assembly"
>> policy language.
>  
> The difficulty with trying to build a higher-level language on top of
> policy language is that, unlike a program that is being executed, there
> is no locality in the policy.  When a problem occurs while a program is
> executing, you can get a stack trace and see what functions were
> executing.  When there is a denial in policy, all you know is that that
> rule does not exist.  There is no way to say where that rule would have
> been if it had existed.  This makes it very hard to abstract away that
> lower level language.
> 
I agree that this is a problem, and it's why our abstraction is so leaky.
The question is how do we solve it. I don't think it makes sense to punt on
the goals of encapsulation and modularity that reference policy was founded
on. Those are real requirements. I know the resultant compiled policy binary
has no concept of modules, but the source definitely does. We have to
support the concept of writing a "policy module" so authors can confine
their applications. As programming and previous policy has shown, modules
without encapsulation are a complete mess.

I guess I'd rather see us complete the abstraction (probably tweaking the
abstraction significantly in the process). Perhaps adding some of the
abstractions to the language itself and storing locality information is a
good step towards this.

This may have been the direction you were already heading. If so, just
dismiss me as being slow.

Chad

>>> 1) The user is constantly presented with types.
>>  
>> Which is perhaps the problem for simplication of development/admin. All I
>> know is that it was impossible to create any type of policy source
>> tools/domain-specific languages when types were gloablly used throughout the
>> sources. Not that I have any concrete suggestions how to improve the
>> situation off hand ;)
>>  
>> Frank
>> 
>>  
>> 
>> 
>> --
>> 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.



--
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.

Re: Are the reference policy abstractions the right ones?

[James Carter]

On Fri, 2007-10-12 at 12:45 -0400, Chad Sellers wrote:
> On 10/11/07 1:00 PM, "Karl MacMillan" <kmacmillan@mentalrootkit.com> wrote:
> 
> > On Wed, 2007-10-10 at 16:39 -0400, Karl MacMillan wrote:
> >> On Wed, 2007-10-10 at 12:52 -0400, James Carter wrote:
> >>> On Wed, 2007-10-10 at 11:23 -0400, Karl MacMillan wrote:
> >>> [...]
> >>>> 
> >>>> Here's a suggestion (this assumes that hierarchy stops using dot in
> >>>> favor of explicit statements):
> >>>> 
> >>>> type_group daemon {
> >>>> type process, domain;
> >>>> type exec, exec_file;
> >>>> type conf, file_type;
> >>>> type log, log_file;
> >>>> }
> >>>> 
> >>> 
> >>> Why not call it type_class?
> >> 
> >> Or type_struct :) I don't really care . . .
> >> 
> >>> 
> >>>> allow daemon.process daemon.exec : file entrypoint;
> >>>> # etc., etc. for the exec permissions - could
> >>>> # even have a type_transition.
> >>>> allow daemon.process daemon.conf : file read;
> >>>> allow daemon.process daemon.log : file { read write };
> >>>> 
> >>> So, process, exec, conf, and log are in scope within the type_group
> >>> block and are referred to outside of that block by identifying the
> >>> namespace using a ".".  Sort of like referring to functions in a python
> >>> module.  Is that right?
> >>> 
> >> 
> >> Yep.
> >> 
> >>>> # Apache gets all of the types defined in daemon and
> >>>> # access to the apache versions - so apache.process
> >>>> # can read apache.conf.
> >>>> type_group apache, daemon {
> >>>> type html_files, file;
> >>>> }
> >>>> 
> >>>> allow apache.process apache.html_files : file read;
> >>>> 
> >>> 
> >>> Would there be allow rules inside the type_group block?  I think that it
> >>> would be needed to distinguish between rules that can be inherited or
> >>> not.
> >>> 
> >>> For example,
> >>> 
> >>> type_group daemon {
> >>> type process, domain;
> >>> 
> >>> allow process foo_t : file read;
> >>> }
> >>> allow daemon.process bar_t : file read;
> >>> 
> >>> type_group apache, daemon {
> >>> ...
> >>> }
> >>> 
> >>> apache.process would not have read access on bar_t, but it would on
> >>> foo_t.
> >>> 
> >> 
> >> That's interesting - I'm having trouble thinking of useful examples
> >> though. And it would need to allow you to add rules "inside" outside of
> >> the original declaration.
> >> 
> > 
> > Thinking about this more - this is actually the same mistake we have
> > already made. Our whole model is that the flexibility has to be
> > anticipated by the policy author ahead of time. Say I create a firefox
> > policy and later some admin wants create a different firefox policy
> > based on that (that, say, limits connections to only the intranet, or
> > prevents writing to the home directory, etc.). Currently the policy
> > author must:
> > 
> > a) make the whole policy into a template
> > b) factor out all of the access that the later author may want to
> > exclude.
> > 
> > It is killing us. So I think we need a way to exclude rules on
> > inheritance. For example:
> > 
> > type_group firefox {
> > type process, domain;
> > type conf, conf_file;
> > }
> > 
> > # bunch of rules, including reading user home dirs and
> > # connect / send / receive anywhere
> > 
> > type_group intranet_firefox {
> > except process user_home_t : file all_file_perms;
> > # also exclude network
> > }
> > 
> > # allow limited network access
> > 
> > No idea about that syntax - they idea is to prevent access from being
> > inherited. These are not deny rules - they only limit inheritance. I
> > think this solves a lot of problems with deny rules - there is no
> > ordering, precedence, or any related problems.
> > 
> > It also gives the flexibility that we have been needing. I also think we
> > should make it easy to except lots of access (e.g., except all access on
> > sockets or all access to a source type). This will make the exception
> > more robust.
> > 
> > So - I'd like to hear from some other people. Are these ideas worth
> > pursuing? The proposals:
> > 
> > 1) remove the distinction between attributes / types.
> > 2) allow nested types / attributes.
> > 3) type_class / type_group
> > 4) exceptions
> > 
> I think these are all very nice features that could definitely come in
> handy. But I'm not sure I see how they address our fundamental problems. I
> agree with you guys that our fundamental problem is the leaky abstractions
> in reference policy. I really don't see how these would solve that problem,
> unless you're proposing that these would negate the need for any
> abstractions. And I don't think that's what you're saying (or is it?).
> 
I am trying to argue that all resources are labeled with types, so it
does no good to try and hide them.  While I don't want to see types used
all over the policy like they were in the old example policy, a few here
and there for inheritance or attribute purposes doesn't seem harmful.
(Famous last words that will probably come back to haunt me.)

I am not arguing that we dump reference policy and get rid of
interfaces.  I do, however, think that nested types and the ability to
inherit with exceptions would give Chris and other policy developers the
ability to write interfaces that fit the common case instead of having
to target the lowest common denominator.  I just don't know how much
they would help.

> Assuming this is a separate part of the conversation geared toward solving
> other problems (not the leaky abstraction problem), then there are some
> pretty cool features here. type_group is essentially a language
> implementation of reference policy templates, so I'd love to see something
> like it. Adding exceptions overcomes one of the main problems with templates
> currently. 
> 
> Chad
> 
> > Karl
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> > 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.
> 
> 
> --
> 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.
-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency


--
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.

Re: Are the reference policy abstractions the right ones?

[Karl MacMillan]

On Fri, 2007-10-12 at 15:53 -0400, James Carter wrote:
> On Fri, 2007-10-12 at 12:45 -0400, Chad Sellers wrote:

[...]

> > > 
> > > So - I'd like to hear from some other people. Are these ideas worth
> > > pursuing? The proposals:
> > > 
> > > 1) remove the distinction between attributes / types.
> > > 2) allow nested types / attributes.
> > > 3) type_class / type_group
> > > 4) exceptions
> > > 
> > I think these are all very nice features that could definitely come in
> > handy. But I'm not sure I see how they address our fundamental problems. I
> > agree with you guys that our fundamental problem is the leaky abstractions
> > in reference policy. I really don't see how these would solve that problem,
> > unless you're proposing that these would negate the need for any
> > abstractions. And I don't think that's what you're saying (or is it?).
> > 
> I am trying to argue that all resources are labeled with types, so it
> does no good to try and hide them.  While I don't want to see types used
> all over the policy like they were in the old example policy, a few here
> and there for inheritance or attribute purposes doesn't seem harmful.
> (Famous last words that will probably come back to haunt me.)
> 
> I am not arguing that we dump reference policy and get rid of
> interfaces.  I do, however, think that nested types and the ability to
> inherit with exceptions would give Chris and other policy developers the
> ability to write interfaces that fit the common case instead of having
> to target the lowest common denominator.  I just don't know how much
> they would help.
> 

That sounds about right to me - I think we should prototype the language
extensions and see what problems they solve. Then we can understand
better how they fit with the reference policy in its current form. I
thought the plan was to add language features to enable the reference
policy anyway. To me, we are just trying to take lessons learned from
the reference policy to continue to move it forward.

Karl



--
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.

Re: Are the reference policy abstractions the right ones?

[Chad Sellers]

On 10/12/07 3:53 PM, "James Carter" <jwcart2@tycho.nsa.gov> wrote:

> On Fri, 2007-10-12 at 12:45 -0400, Chad Sellers wrote:
>> On 10/11/07 1:00 PM, "Karl MacMillan" <kmacmillan@mentalrootkit.com> wrote:
>> 
>>> On Wed, 2007-10-10 at 16:39 -0400, Karl MacMillan wrote:
>>>> On Wed, 2007-10-10 at 12:52 -0400, James Carter wrote:
>>>>> On Wed, 2007-10-10 at 11:23 -0400, Karl MacMillan wrote:
>>>>> [...]
>>>>>> 
>>>>>> Here's a suggestion (this assumes that hierarchy stops using dot in
>>>>>> favor of explicit statements):
>>>>>> 
>>>>>> type_group daemon {
>>>>>> type process, domain;
>>>>>> type exec, exec_file;
>>>>>> type conf, file_type;
>>>>>> type log, log_file;
>>>>>> }
>>>>>> 
>>>>> 
>>>>> Why not call it type_class?
>>>> 
>>>> Or type_struct :) I don't really care . . .
>>>> 
>>>>> 
>>>>>> allow daemon.process daemon.exec : file entrypoint;
>>>>>> # etc., etc. for the exec permissions - could
>>>>>> # even have a type_transition.
>>>>>> allow daemon.process daemon.conf : file read;
>>>>>> allow daemon.process daemon.log : file { read write };
>>>>>> 
>>>>> So, process, exec, conf, and log are in scope within the type_group
>>>>> block and are referred to outside of that block by identifying the
>>>>> namespace using a ".".  Sort of like referring to functions in a python
>>>>> module.  Is that right?
>>>>> 
>>>> 
>>>> Yep.
>>>> 
>>>>>> # Apache gets all of the types defined in daemon and
>>>>>> # access to the apache versions - so apache.process
>>>>>> # can read apache.conf.
>>>>>> type_group apache, daemon {
>>>>>> type html_files, file;
>>>>>> }
>>>>>> 
>>>>>> allow apache.process apache.html_files : file read;
>>>>>> 
>>>>> 
>>>>> Would there be allow rules inside the type_group block?  I think that it
>>>>> would be needed to distinguish between rules that can be inherited or
>>>>> not.
>>>>> 
>>>>> For example,
>>>>> 
>>>>> type_group daemon {
>>>>> type process, domain;
>>>>> 
>>>>> allow process foo_t : file read;
>>>>> }
>>>>> allow daemon.process bar_t : file read;
>>>>> 
>>>>> type_group apache, daemon {
>>>>> ...
>>>>> }
>>>>> 
>>>>> apache.process would not have read access on bar_t, but it would on
>>>>> foo_t.
>>>>> 
>>>> 
>>>> That's interesting - I'm having trouble thinking of useful examples
>>>> though. And it would need to allow you to add rules "inside" outside of
>>>> the original declaration.
>>>> 
>>> 
>>> Thinking about this more - this is actually the same mistake we have
>>> already made. Our whole model is that the flexibility has to be
>>> anticipated by the policy author ahead of time. Say I create a firefox
>>> policy and later some admin wants create a different firefox policy
>>> based on that (that, say, limits connections to only the intranet, or
>>> prevents writing to the home directory, etc.). Currently the policy
>>> author must:
>>> 
>>> a) make the whole policy into a template
>>> b) factor out all of the access that the later author may want to
>>> exclude.
>>> 
>>> It is killing us. So I think we need a way to exclude rules on
>>> inheritance. For example:
>>> 
>>> type_group firefox {
>>> type process, domain;
>>> type conf, conf_file;
>>> }
>>> 
>>> # bunch of rules, including reading user home dirs and
>>> # connect / send / receive anywhere
>>> 
>>> type_group intranet_firefox {
>>> except process user_home_t : file all_file_perms;
>>> # also exclude network
>>> }
>>> 
>>> # allow limited network access
>>> 
>>> No idea about that syntax - they idea is to prevent access from being
>>> inherited. These are not deny rules - they only limit inheritance. I
>>> think this solves a lot of problems with deny rules - there is no
>>> ordering, precedence, or any related problems.
>>> 
>>> It also gives the flexibility that we have been needing. I also think we
>>> should make it easy to except lots of access (e.g., except all access on
>>> sockets or all access to a source type). This will make the exception
>>> more robust.
>>> 
>>> So - I'd like to hear from some other people. Are these ideas worth
>>> pursuing? The proposals:
>>> 
>>> 1) remove the distinction between attributes / types.
>>> 2) allow nested types / attributes.
>>> 3) type_class / type_group
>>> 4) exceptions
>>> 
>> I think these are all very nice features that could definitely come in
>> handy. But I'm not sure I see how they address our fundamental problems. I
>> agree with you guys that our fundamental problem is the leaky abstractions
>> in reference policy. I really don't see how these would solve that problem,
>> unless you're proposing that these would negate the need for any
>> abstractions. And I don't think that's what you're saying (or is it?).
>> 
> I am trying to argue that all resources are labeled with types, so it
> does no good to try and hide them.  While I don't want to see types used
> all over the policy like they were in the old example policy, a few here
> and there for inheritance or attribute purposes doesn't seem harmful.
> (Famous last words that will probably come back to haunt me.)
> 
Famous last words indeed ;-)

> I am not arguing that we dump reference policy and get rid of
> interfaces.  I do, however, think that nested types and the ability to
> inherit with exceptions would give Chris and other policy developers the
> ability to write interfaces that fit the common case instead of having
> to target the lowest common denominator.  I just don't know how much
> they would help.
> 
>> Assuming this is a separate part of the conversation geared toward solving
>> other problems (not the leaky abstraction problem), then there are some
>> pretty cool features here. type_group is essentially a language
>> implementation of reference policy templates, so I'd love to see something
>> like it. Adding exceptions overcomes one of the main problems with templates
>> currently. 
>> 
>> Chad
>> 
>>> Karl
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> 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.
>> 
>> 
>> --
>> 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.



--
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.

Re: Are the reference policy abstractions the right ones?

[James Morris]

On Thu, 11 Oct 2007, Karl MacMillan wrote:

> So - I'd like to hear from some other people. Are these ideas worth
> pursuing? The proposals:
> 
> 1) remove the distinction between attributes / types.
> 2) allow nested types / attributes.
> 3) type_class / type_group
> 4) exceptions

I think moving to a general OO model at a higher level is desirable, and 
that we need to go beyond simply 'type' in #3 and look at OO classes which 
encapsulate all SELinux-related attributes (permissions, labeling rules, 
network policy, booleans etc).

People are increasingly utilizing containers/VMs/appliances to manage and 
isolate their applications, and I think that this is also a means for us 
to provide higher-level SELinux abstractions.

With comprehensive SELinux classes, we could:

- Bind security classes to various levels of system abstraction, and thus 
  bind security objects to a variety of types of encapsulating objects 
  (e.g. RPM, VM, container, tarball, standalone file);

- Modify classes via inheritance (already discussed somewhat);

- Define high-level interactions between classes via well-defined 
  interfaces;

- Compose classes into higher-level classes in a structured, analyzable 
  manner.

With the latter being an important way to allow admins to configure 
overall security at a meaningful level of granularity, matching the level 
of encapsulation which they are already using for managing applications.

The idea generally being that admins/developers not think in terms of low 
level policy constructs (although allow these to be exposed if needed), 
but rather, to think about composing security objects into e.g. a 
container, and then from a system point of view, to be able to broadly 
define how the containers interact with each other and the base system.


Thoughts?


- James
-- 
James Morris
<jmorris@namei.org>

--
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.

Re: Are the reference policy abstractions the right ones?

[Joe Nall]

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]


On Oct 14, 2007, at 9:50 PM, James Morris wrote:

> On Thu, 11 Oct 2007, Karl MacMillan wrote:
>
>> So - I'd like to hear from some other people. Are these ideas worth
>> pursuing? The proposals:
>>
>> 1) remove the distinction between attributes / types.
>> 2) allow nested types / attributes.
>> 3) type_class / type_group
>> 4) exceptions
>
> I think moving to a general OO model at a higher level is  
> desirable, and
> that we need to go beyond simply 'type' in #3 and look at OO  
> classes which
> encapsulate all SELinux-related attributes (permissions, labeling  
> rules,
> network policy, booleans etc).
>
> People are increasingly utilizing containers/VMs/appliances to  
> manage and
> isolate their applications, and I think that this is also a means  
> for us
> to provide higher-level SELinux abstractions.
>
> With comprehensive SELinux classes, we could:
>
> - Bind security classes to various levels of system abstraction,  
> and thus
>   bind security objects to a variety of types of encapsulating objects
>   (e.g. RPM, VM, container, tarball, standalone file);
>
> - Modify classes via inheritance (already discussed somewhat);
>
> - Define high-level interactions between classes via well-defined
>   interfaces;
>
> - Compose classes into higher-level classes in a structured,  
> analyzable
>   manner.
>
> With the latter being an important way to allow admins to configure
> overall security at a meaningful level of granularity, matching the  
> level
> of encapsulation which they are already using for managing  
> applications.
>
> The idea generally being that admins/developers not think in terms  
> of low
> level policy constructs (although allow these to be exposed if  
> needed),
> but rather, to think about composing security objects into e.g. a
> container, and then from a system point of view, to be able to broadly
> define how the containers interact with each other and the base  
> system.
>
>
> Thoughts?

Brooks Second System Syndrome

joe


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2880 bytes --]

Re: Are the reference policy abstractions the right ones?

[James Morris]

On Sun, 14 Oct 2007, Joe Nall wrote:

> Brooks Second System Syndrome

This would be a layer on top of the existing policy scheme, not a 
wholesale replacement.


-- 
James Morris
<jmorris@namei.org>

--
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.

Re: Are the reference policy abstractions the right ones?

[David P. Quigley]

I personally like the ideas that James has put forth here. My Master's
thesis work that I finished about half a year ago was along these lines.
My system did suffer from second system syndrome because it was built on
top of the existing policy language however it might bring up some
interesting ideas. The paper can be found at
http://www.fsl.cs.sunysb.edu/project-please.html in pdf, ps, and html
formats. The relevant sections are 3, 5 and Appendix A (and B if you
want to see the language grammar). I don't necessarily know if this is
the direction we want to move in however I do believe some of the ideas
could be useful for evolution of the policy language. If people had time
to look over it and comment I would greatly appreciate it.

Dave Quigley

P.S Sorry for the double post James I forgot to hit reply all instead of
reply.

On Mon, 2007-10-15 at 12:50 +1000, James Morris wrote:
> On Thu, 11 Oct 2007, Karl MacMillan wrote:
> 
> > So - I'd like to hear from some other people. Are these ideas worth
> > pursuing? The proposals:
> > 
> > 1) remove the distinction between attributes / types.
> > 2) allow nested types / attributes.
> > 3) type_class / type_group
> > 4) exceptions
> 
> I think moving to a general OO model at a higher level is desirable, and 
> that we need to go beyond simply 'type' in #3 and look at OO classes which 
> encapsulate all SELinux-related attributes (permissions, labeling rules, 
> network policy, booleans etc).
> 
> People are increasingly utilizing containers/VMs/appliances to manage and 
> isolate their applications, and I think that this is also a means for us 
> to provide higher-level SELinux abstractions.
> 
> With comprehensive SELinux classes, we could:
> 
> - Bind security classes to various levels of system abstraction, and thus 
>   bind security objects to a variety of types of encapsulating objects 
>   (e.g. RPM, VM, container, tarball, standalone file);
> 
> - Modify classes via inheritance (already discussed somewhat);
> 
> - Define high-level interactions between classes via well-defined 
>   interfaces;
> 
> - Compose classes into higher-level classes in a structured, analyzable 
>   manner.
> 
> With the latter being an important way to allow admins to configure 
> overall security at a meaningful level of granularity, matching the level 
> of encapsulation which they are already using for managing applications.
> 
> The idea generally being that admins/developers not think in terms of low 
> level policy constructs (although allow these to be exposed if needed), 
> but rather, to think about composing security objects into e.g. a 
> container, and then from a system point of view, to be able to broadly 
> define how the containers interact with each other and the base system.
> 
> 
> Thoughts?
> 
> 
> - James

--
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.

Re: Are the reference policy abstractions the right ones?

[Karl MacMillan]

On Mon, 2007-10-15 at 12:50 +1000, James Morris wrote:
> On Thu, 11 Oct 2007, Karl MacMillan wrote:
> 
> > So - I'd like to hear from some other people. Are these ideas worth
> > pursuing? The proposals:
> > 
> > 1) remove the distinction between attributes / types.
> > 2) allow nested types / attributes.
> > 3) type_class / type_group
> > 4) exceptions
> 
> I think moving to a general OO model at a higher level is desirable, and 
> that we need to go beyond simply 'type' in #3 and look at OO classes which 
> encapsulate all SELinux-related attributes (permissions,

Do you mean abstract permissions - what are currently interfaces? I
agree - something like:

# daemon started from init
type_class init_daemon {
	type process;
	type pid_file;
	type log_file;
	interface manage(type domain) {
		# allow r/w to pid and log
		# and signal to process
	}
}

# daemon that uses the network
type_class network_daemon, init_daemon {
	interface manage(type domain) {
		# add access unique to this type_class
		# other access should chain by default.
		# May need to be able to disable chaining.
	}
}

type_class apache, network_daemon;

# call the interface - this looks backwards to me
apache.manage(sysadm_t);

# alternative syntax - this keeps subject / object ordering,
# but we can't pass multiple args this way. And should the
# separator be something other than "."?
allow sysadm_t apache.manage;

Of course there are details - like we want to be able to add these after
the initial type_class definition. Actually, I'd like the definitions to
be "open" for later modification in general. That way I could add a new
type to every network_daemon for example.

> labeling rules, 

This one is not clear to me. Every time you inherit from a type_class
you are creating new types which, almost by definition, should have
separate labeling from parent types. When the labeling should be the
same you likely want to factor out the type.

Take exec types as an example - you likely want those outside of the
type class.

type firefox_exec_t; # shared among all firefox domains
type_class firefox {
	type process, domain;
	type config, file_type; # likely polyinstantiated ~/.mozilla
}

# new firefox - still gets entrypoint for
# firefox_exec_t
type class intranet_firefox, firefox;

Of course, this brings up questions about transitions. Transitions to
the process types should likely be dropped (auto-inserting them would
just cause conflicts), but transitions from the process types (like for
helper apps) should likely be kept. They can be excluded if desired.

> network policy,

Not certain what you mean here - isn't that just packet types?

>  booleans etc).
> 

Agreed. So in generaly I definitely agree and we may need to call it
something other than type_class. Suggestions welcome.

> People are increasingly utilizing containers/VMs/appliances to manage and 
> isolate their applications, and I think that this is also a means for us 
> to provide higher-level SELinux abstractions.
> 
> With comprehensive SELinux classes, we could:
> 
> - Bind security classes to various levels of system abstraction, and thus 
>   bind security objects to a variety of types of encapsulating objects 
>   (e.g. RPM, VM, container, tarball, standalone file);
> 
> - Modify classes via inheritance (already discussed somewhat);
> 
> - Define high-level interactions between classes via well-defined 
>   interfaces;
> 
> - Compose classes into higher-level classes in a structured, analyzable 
>   manner.
> 
> With the latter being an important way to allow admins to configure 
> overall security at a meaningful level of granularity, matching the level 
> of encapsulation which they are already using for managing applications.
> 
> The idea generally being that admins/developers not think in terms of low 
> level policy constructs (although allow these to be exposed if needed), 
> but rather, to think about composing security objects into e.g. a 
> container, and then from a system point of view, to be able to broadly 
> define how the containers interact with each other and the base system.

I agree with the general idea. The devil will be in the details. There
also isn't really a good container to reuse. Virtual machines are too
separate, we need something where there is the possibility of controlled
sharing. Hardened chroots / jails I guess or perhaps one of the other
light-weight containers.

Though this won't solve all problems, I do think that making it easy to
use containers is important.

Karl


--
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.

Re: Are the reference policy abstractions the right ones?

[James Morris]

On Mon, 15 Oct 2007, Karl MacMillan wrote:

> On Mon, 2007-10-15 at 12:50 +1000, James Morris wrote:
> > On Thu, 11 Oct 2007, Karl MacMillan wrote:
> > 
> > > So - I'd like to hear from some other people. Are these ideas worth
> > > pursuing? The proposals:
> > > 
> > > 1) remove the distinction between attributes / types.
> > > 2) allow nested types / attributes.
> > > 3) type_class / type_group
> > > 4) exceptions
> > 
> > I think moving to a general OO model at a higher level is desirable, and 
> > that we need to go beyond simply 'type' in #3 and look at OO classes which 
> > encapsulate all SELinux-related attributes (permissions,
> 
> Do you mean abstract permissions - what are currently interfaces? I
> agree - something like:
> 
> # daemon started from init
> type_class init_daemon {
> 	type process;
> 	type pid_file;
> 	type log_file;
> 	interface manage(type domain) {
> 		# allow r/w to pid and log
> 		# and signal to process
> 	}
> }

Yes.

> > labeling rules, 
> 
> This one is not clear to me. Every time you inherit from a type_class
> you are creating new types which, almost by definition, should have
> separate labeling from parent types. When the labeling should be the
> same you likely want to factor out the type.

The reason for it is twofold:
 - allow binding of the class to OS objects
 - allow the labeling rules to be modified via inheritance

So, someone wanting to customize their httpd would subclass the httpd 
security object, which would also need a new name, and potentially 
override the labeling rules (e.g. different paths to files).

> > network policy,
> 
> Not certain what you mean here - isn't that just packet types?

Things like netfilter contexts, port labels etc. which can be collected 
together into a class under this scheme.

> I agree with the general idea. The devil will be in the details. There
> also isn't really a good container to reuse. Virtual machines are too
> separate, we need something where there is the possibility of controlled
> sharing. Hardened chroots / jails I guess or perhaps one of the other
> light-weight containers.
> 
> Though this won't solve all problems, I do think that making it easy to
> use containers is important.

I was thinking of allowing flexibility with the granularity of the class, 
allowing it to be constructed in a way which matched the granularity at 
which the admin is managing the system.  Containers are just one example, 
where you might have a class composed of other classes, with the top level 
being itself a container, bound to the OS container.

e.g. for a VM, you'd have a "vm" class containing "base_os" class and the 
application class.  So, everything needed is packaged with the VM (or 
whatever: RPM, tarball).  The admin would configure the security of the 
overall system via a relatively simple config file which specifies 
interactions between these encapsulating objects (in this case, vm-vm and 
vm-host policy).

This allows the low-level policy to be hidden via encapsulation, and for 
the admin to be able to think at a higher level in terms of how components 
interact.


- James
-- 
James Morris 
<jmorris@namei.org>

--
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.

Re: Are the reference policy abstractions the right ones?

[Karl MacMillan]

On Tue, 2007-10-16 at 07:15 +1000, James Morris wrote:
> On Mon, 15 Oct 2007, Karl MacMillan wrote:
> 

[...]

> > > labeling rules, 
> > 
> > This one is not clear to me. Every time you inherit from a type_class
> > you are creating new types which, almost by definition, should have
> > separate labeling from parent types. When the labeling should be the
> > same you likely want to factor out the type.
> 
> The reason for it is twofold:
>  - allow binding of the class to OS objects
>  - allow the labeling rules to be modified via inheritance
> 
> So, someone wanting to customize their httpd would subclass the httpd 
> security object, which would also need a new name, and potentially 
> override the labeling rules (e.g. different paths to files).
> 

It seems that wanting to _not_ override the rules would only occur in
the case of a container (and even there I'm not certain that is true -
it seems safer to always state the labeling from outside of the
container). So the common case (and the only one possible today) is that
you would always override the rules.

> > > network policy,
> > 
> > Not certain what you mean here - isn't that just packet types?
> 
> Things like netfilter contexts, port labels etc. which can be collected 
> together into a class under this scheme.
> 

These are all handled as types, correct?

> > I agree with the general idea. The devil will be in the details. There
> > also isn't really a good container to reuse. Virtual machines are too
> > separate, we need something where there is the possibility of controlled
> > sharing. Hardened chroots / jails I guess or perhaps one of the other
> > light-weight containers.
> > 
> > Though this won't solve all problems, I do think that making it easy to
> > use containers is important.
> 
> I was thinking of allowing flexibility with the granularity of the class, 
> allowing it to be constructed in a way which matched the granularity at 
> which the admin is managing the system.  Containers are just one example, 
> where you might have a class composed of other classes, with the top level 
> being itself a container, bound to the OS container.
> 
> e.g. for a VM, you'd have a "vm" class containing "base_os" class and the 
> application class.  So, everything needed is packaged with the VM (or 
> whatever: RPM, tarball).  The admin would configure the security of the 
> overall system via a relatively simple config file which specifies 
> interactions between these encapsulating objects (in this case, vm-vm and 
> vm-host policy).
> 
> This allows the low-level policy to be hidden via encapsulation, and for 
> the admin to be able to think at a higher level in terms of how components 
> interact.
> 

I agree about the general point, but not your specific example. Do we
really want every VM to have a unique policy? That would force us to
always do label translation when talking over the network, adding
complexity rather than removing it.

Karl

> 
> - James


--
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.