ANN: SELinux Reference Policy Release

ANN: SELinux Reference Policy Release

[Christopher J. PeBenito]

The first release of the SELinux Reference Policy is now available on
Sourceforge from http://serefpolicy.sourceforge.net.

This is an experimental release, and definitely is not usable as a
drop-in replacement for the current policy, as it can only boot a very
limited RHEL4 system.  It is directed towards policy developers, to
generate community feedback and discussion.

Any feedback is welcome.

-- 
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: ANN: SELinux Reference Policy Release

[Colin Walters]

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

On Wed, 2005-06-15 at 17:42 -0400, Christopher J. PeBenito wrote:
> The first release of the SELinux Reference Policy is now available on
> Sourceforge from http://serefpolicy.sourceforge.net.
> 
> This is an experimental release, and definitely is not usable as a
> drop-in replacement for the current policy, as it can only boot a very
> limited RHEL4 system.  It is directed towards policy developers, to
> generate community feedback and discussion.

Wow.  This looks quite fantastic.  I really, really like the inline
documentation work.

This work reminds me though; I was thinking a week or so ago about what
it would be like to write e.g. an Eclipse plugin for policy writing.
One of the core problems one would run into (and I bet the polgen people
hit this too) is that it's a nightmare to deal with m4; how do you know
what macros are available and what they do?  The macros form the real
policy language, so an IDE would need to understand them.

You're left with basically hardcoding a list of them, or resorting to
some evil hack to try to extract the macro names and filter unwanted
macros.

The inline documentation in the reference policy is really a form of
easily parseable metadata that could also be used for this purpose.
However, it's a bit verbose now.  Let's take an example:

########################################
## <interface name="selinux_get_enforce_mode">
##      <description>
##              Allows the caller to get the mode of policy enforcement
##              (enforcing or permissive mode).
##      </description>
##      <parameter name="domain">
##              The process type to allow to get the enforcing mode.
##      </parameter>
## </interface>
#
define(`selinux_get_enforce_mode',`
        gen_require(`$0'_depend)

        allow $1 security_t:dir { read search getattr };
        allow $1 security_t:file { getattr read };
')

You have to declare "selinux_get_enforce_mode" twice; it's verbose
and error-prone.

What if we actually extended checkpolicy with the notion of "policy
functions"?  For example, suppose we had syntax like this:

# Allows the caller to get the mode of policy enforcement (enforcing or
# permissive)
# @param basetype The process type to allow to get the enforcing mode.
function selinux_get_enforce_mode(domain basetype) {
  allow basetype security_t:dir { read search getattr };
  allow basetype security_t:file { getattr read };
}

Much nicer, no?

Ok, so that's a pretty simple function; here's a more complicated
example, from your apps/gpg.if:

#######################################
#
# Per user domain template for this module
#
# gpg_per_userdomain_template(userdomain_prefix)
#
define(`gpg_per_userdomain_template',`
        type $1_gpg_t;
        domain_type($1_gpg_t)
        domain_entry_file($1_gpg_t,gpg_exec_t)
        role $1_r types $1_gpg_t;

        ...

        # transition from the userdomain to the derived domain
        allow $1_t $1_gpg_t:process transition;
        allow $1_t gpg_exec_t:file rx_file_perms;
        type_transition $1_t gpg_exec_t:process $1_gpg_t;

        ...

Wouldn't it be nice if we could do instead:

# Define derived domains for GPG from @userdomain
# @param user The user domain to derive from
# @param userrole The user role to authorize for GPG
function gpg_per_userdomain(domain user, role userrole) {
  derivedtype gpg_t from user

  domain_type(gpg_t)
  domain_entry_file(gpg_t, gpg_exec_t)
  role userrole types gpg_t

  ...

  allow user gpg_t:process transition;
  allow user gpg_exec_t:file rx_file_perms;
  type_transition user gpg_exec_t:process gpg_t;

  ...
}

The key idea here is that an IDE could actually parse this, and easily
determine programatically what types and roles are generated by the
function, without doing hacks like expanding the M4 and parsing that,
and then guessing.

Your policy modules work removes one of the major uses of M4 in the
policy (that being ifdef(`foo.te')), and having policy functions would
kill the other major use.

Since you're embarking on rewriting the policy, I thought I'd bring this
up now.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ANN: SELinux Reference Policy Release

[antoine]

(...)
Good work!

> # Define derived domains for GPG from @userdomain
> # @param user The user domain to derive from
> # @param userrole The user role to authorize for GPG
> function gpg_per_userdomain(domain user, role userrole) {
>   derivedtype gpg_t from user
> 
>   domain_type(gpg_t)
>   domain_entry_file(gpg_t, gpg_exec_t)
>   role userrole types gpg_t
> 
>   ...
> 
> The key idea here is that an IDE could actually parse this,
Not just IDEs, my brain finds it easier to parse too.
XML if overused nowadays.

>  and easily
> determine programatically what types and roles are generated by the
> function, without doing hacks like expanding the M4 and parsing that,
> and then guessing.
Absolutely.

Antoine


--
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: ANN: SELinux Reference Policy Release

[Christopher J. PeBenito]

On Thu, 2005-06-16 at 00:25 +0100, antoine wrote:
> (...)
> Good work!
> 
> > # Define derived domains for GPG from @userdomain
> > # @param user The user domain to derive from
> > # @param userrole The user role to authorize for GPG
> > function gpg_per_userdomain(domain user, role userrole) {
> >   derivedtype gpg_t from user
> > 
> >   domain_type(gpg_t)
> >   domain_entry_file(gpg_t, gpg_exec_t)
> >   role userrole types gpg_t
> > 
> >   ...
> > 
> > The key idea here is that an IDE could actually parse this,
> Not just IDEs, my brain finds it easier to parse too.
> XML if overused nowadays.

The inline documentation was meant to be machine parseable.  Its used to
create the interface documentation on the website
(http://serefpolicy.sourceforge.net/api-docs/), which is much more
readable, and also to create the modules.conf and tunables.conf files.
Also, as Karl mentioned, it was meant to be loaded into other tools,
such as SEFramework
(http://www.selinux-symposium.org/2005/presentations/session6/6-1-wilson.pdf).

We did look into other available formats for machine parseable comments,
and XML is really the best choice if you want the comments to be
transformed into many different formats, and easily loaded into other
programs; its already well understood, and parsers exist for many
programming languages.  Simpler (for humans to read) commenting formats
just don't have these options, and mainly target one transformation.

> >  and easily
> > determine programatically what types and roles are generated by the
> > function, without doing hacks like expanding the M4 and parsing that,
> > and then guessing.
> Absolutely.

It is more complex then that, because you still have to take into
account *'s and ~'s and attributes.  We've thought about this problem a
little, and we'll be looking more into this in the future.

-- 
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: ANN: SELinux Reference Policy Release

[Lorenzo Hernández García-Hierro]

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

El jue, 16-06-2005 a las 09:55 -0400, Christopher J. PeBenito escribió:
> We did look into other available formats for machine parseable comments,
> and XML is really the best choice if you want the comments to be
> transformed into many different formats, and easily loaded into other
> programs; its already well understood, and parsers exist for many
> programming languages.  Simpler (for humans to read) commenting formats
> just don't have these options, and mainly target one transformation.

A modified Gnome-doc (ie. Kernel-doc) might be an interesting option.
It would be a matter of modifying the lex and other stuff to make it
parsing our own commenting style within the policy files.

Cheers,
-- 
Lorenzo Hernández García-Hierro <lorenzo@gnu.org>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ANN: SELinux Reference Policy Release

[antoine]

> El jue, 16-06-2005 a las 09:55 -0400, Christopher J. PeBenito escribió:
> > We did look into other available formats for machine parseable comments,
> > and XML is really the best choice if you want the comments to be
> > transformed into many different formats, and easily loaded into other
> > programs; its already well understood, and parsers exist for many
> > programming languages.  Simpler (for humans to read) commenting formats
> > just don't have these options, and mainly target one transformation.
As long as that transformation is the XML one, we are ok. Just an extra
step needed when using the XML data which should not be a problem.

> A modified Gnome-doc (ie. Kernel-doc) might be an interesting option.
> It would be a matter of modifying the lex and other stuff to make it
> parsing our own commenting style within the policy files.
Yes. How about using a more human-readable format *with* the ability to
generate the long-winded XML from it so we get the benefit of both?
I am not just suggesting this for someone else to do, if you think this
is worth doing I would be willing to write the code myself.

Example:
/**
  * @interface selinux_get_enforce_mode
  * @description Allows the caller to get the mode of policy enforcement
  *         (enforcing or permissive mode).
  * @param domain The process type to allow to get the enforcing mode.
  */
Could easily be translated to the XML that was given as example:
########################################
## <interface name="selinux_get_enforce_mode">
##      <description>
##              Allows the caller to get the mode of policy enforcement
##              (enforcing or permissive mode).
##      </description>
##      <parameter name="domain">
##              The process type to allow to get the enforcing mode.
##      </parameter>
## </interface>
#
Now which one do you prefer?
I am not against XML on principle (I have used SGML/XML since 1995) just
trying to keep things human readable as much as possible.
We could also the use the @return notation to show which domains are
created by the macro:
@return mydomain_tmp_t, mydomain_var_t, etc

> We have some Java code lying around that can parse the generated XML
> if you want it. We are also working on an eclipse based policy
> development environment.
Is there any code publicly available?

Antoine


--
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: ANN: SELinux Reference Policy Release

[Karl MacMillan]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of antoine
> Sent: Tuesday, June 21, 2005 7:26 PM
> To: Lorenzo Hernández García-Hierro
> Cc: Christopher J. PeBenito; Colin Walters; SELinux Mail List
> Subject: Re: ANN: SELinux Reference Policy Release
> 
> > El jue, 16-06-2005 a las 09:55 -0400, Christopher J. PeBenito escribió:
> > > We did look into other available formats for machine parseable comments,
> > > and XML is really the best choice if you want the comments to be
> > > transformed into many different formats, and easily loaded into other
> > > programs; its already well understood, and parsers exist for many
> > > programming languages.  Simpler (for humans to read) commenting formats
> > > just don't have these options, and mainly target one transformation.
> As long as that transformation is the XML one, we are ok. Just an extra
> step needed when using the XML data which should not be a problem.
> 
> > A modified Gnome-doc (ie. Kernel-doc) might be an interesting option.
> > It would be a matter of modifying the lex and other stuff to make it
> > parsing our own commenting style within the policy files.
> Yes. How about using a more human-readable format *with* the ability to
> generate the long-winded XML from it so we get the benefit of both?
> I am not just suggesting this for someone else to do, if you think this
> is worth doing I would be willing to write the code myself.
> 

See below for my thoughts on the format. If you are interested in helping we
would be happy for any contributions. The sf cvs is updated nightly. We should
get what we view as the task list up on the website soon and welcome any
suggestions for what should be accomplished in the near or long term. 

> Example:
> /**
>   * @interface selinux_get_enforce_mode
>   * @description Allows the caller to get the mode of policy enforcement
>   *         (enforcing or permissive mode).
>   * @param domain The process type to allow to get the enforcing mode.
>   */
> Could easily be translated to the XML that was given as example:
> ########################################
> ## <interface name="selinux_get_enforce_mode">
> ##      <description>
> ##              Allows the caller to get the mode of policy enforcement
> ##              (Allows the caller to get the mode of policy enforcement > ##
</description>
> ##      <parameter name="domain">
> ##              The process type to allow to get the enforcing mode.
> ##      </parameter>
> ## </interface>
> #
> Now which one do you prefer?
> I am not against XML on principle (I have used SGML/XML since 1995) just
> trying to keep things human readable as much as possible.

I think that we can make this more readable without punting on the xml (which I
actually think is easier to read than the javadoc style @ tags). We are going to
trim down the XML to look more like:

## 
## <description>
##	Allows the caller to get the mode of policy enforcement
## </description>
##
## <param name="domain">
## 	The process type to allow to get the enforcing mode.
## </param>
##

That means that the interface name will be derived from the actual interface
declaration, which should probably be changed to a macro for declaring
interfaces. The final xml file that is output won't change, we will just
generate some of the tags. Thoughts?

> We could also the use the @return notation to show which domains are
> created by the macro:
> @return mydomain_tmp_t, mydomain_var_t, etc
> 

Reference policy macros _never_ create types. A macro that defines a new type 1)
breaks encapsulation and 2) means that the policy author has to muck around in
either the docs or the implementation to figure out what types were created.

> > We have some Java code lying around that can parse the generated XML
> > if you want it. We are also working on an eclipse based policy
> > development environment.
> Is there any code publicly available?
> 

Not yet - if you want the parsing code I can release it though.

Karl

> Antoine
> 
> 
> --
> 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: ANN: SELinux Reference Policy Release

[Lorenzo Hernández García-Hierro]

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

El mar, 21-06-2005 a las 21:47 -0400, Karl MacMillan escribió:
> See below for my thoughts on the format. If you are interested in helping we
> would be happy for any contributions. The sf cvs is updated nightly. We should
> get what we view as the task list up on the website soon and welcome any
> suggestions for what should be accomplished in the near or long term. 

I will be glad to help during this summer for sure, just lemme know
about the group of people going to work over it and we can try to
organize a common schedule for it, as it seems a huge job which needs a
well organized development and deployment process. (Well, some are
getting paid for it ;) ).

The road-map in http://serefpolicy.sourceforge.net/ doesn't look
meaningful to me though.

> I think that we can make this more readable without punting on the xml (which I
> actually think is easier to read than the javadoc style @ tags). We are going to
> trim down the XML to look more like:
> 
> ## 
> ## <description>
> ##	Allows the caller to get the mode of policy enforcement
> ## </description>
> ##
> ## <param name="domain">
> ## 	The process type to allow to get the enforcing mode.
> ## </param>
> ##

So, we strip out the '##', then parse each "chain" (should we
concatenate it and thus making an only one XML file with the whole
reference?), and then use the proper style-sheet to run the formatting?

It makes sense but a per-file basis approach would be more easy to
deploy, anyways, more challenge, more fun.

> That means that the interface name will be derived from the actual interface
> declaration, which should probably be changed to a macro for declaring
> interfaces. The final xml file that is output won't change, we will just
> generate some of the tags. Thoughts?

 - for each file (.te, .fc, ...) we strip out the commented XML
   - we dump it in a xml/dir/file.extension
     - we concatenate each file.{fc, te, ...}
      - we produce a single XML file
        - we're done for parsing and doing any formatting on top of the
          source XML file.

Though It's not the best time to think about it, will give it a further
look later.

How it looks to you?

> Not yet - if you want the parsing code I can release it though.

It would be good to have all-in-place. With single, separated pieces we
can't do it, either we have everything clear and well exposed in the
proper place or we have nothing.

I'm new around this (the ref. policy) and also on the policy itself, I'm
still not too familiar with it (hadn't enough time to deal with it
properly), so, I may be wrong, then please give advice and I'll try to
make it going smooth and straight forward ;).

Cheers,
-- 
Lorenzo Hernández García-Hierro <lorenzo@gnu.org>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: ANN: SELinux Reference Policy Release

[Karl MacMillan]

> -----Original Message-----
> From: Lorenzo Hernández García-Hierro [mailto:lorenzo@gnu.org]
> Sent: Tuesday, June 21, 2005 10:31 PM
> To: Karl MacMillan
> Cc: 'antoine'; 'Christopher J. PeBenito'; 'Colin Walters'; 'SELinux Mail List'
> Subject: RE: ANN: SELinux Reference Policy Release
> 
> El mar, 21-06-2005 a las 21:47 -0400, Karl MacMillan escribió:
> > See below for my thoughts on the format. If you are interested in helping we
> > would be happy for any contributions. The sf cvs is updated nightly. We
> should
> > get what we view as the task list up on the website soon and welcome any
> > suggestions for what should be accomplished in the near or long term.
> 
> I will be glad to help during this summer for sure, just lemme know
> about the group of people going to work over it and we can try to
> organize a common schedule for it, as it seems a huge job which needs a
> well organized development and deployment process. (Well, some are
> getting paid for it ;) ).
> 
> The road-map in http://serefpolicy.sourceforge.net/ doesn't look
> meaningful to me though.
>

Ok - not certain what is not meaningful about the roadmap. I am working on a
more detailed schedule that I will post on the website.

 
> > I think that we can make this more readable without punting on the xml
> (which I
> > actually think is easier to read than the javadoc style @ tags). We are
> going to
> > trim down the XML to look more like:
> >
> > ##
> > ## <description>
> > ##	Allows the caller to get the mode of policy enforcement
> > ## </description>
> > ##
> > ## <param name="domain">
> > ## 	The process type to allow to get the enforcing mode.
> > ## </param>
> > ##
> 
> So, we strip out the '##', then parse each "chain" (should we
> concatenate it and thus making an only one XML file with the whole
> reference?), and then use the proper style-sheet to run the formatting?
> 
> It makes sense but a per-file basis approach would be more easy to
> deploy, anyways, more challenge, more fun.
> 

Not certain what you mean - the plan is to generate a single XML file that
represents the entire policy. From that point it can be manipulated however we
want. The current tool for generating the docs will continue to work with minor
changes to convert this to html.

> > That means that the interface name will be derived from the actual interface
> > declaration, which should probably be changed to a macro for declaring
> > interfaces. The final xml file that is output won't change, we will just
> > generate some of the tags. Thoughts?
> 
>  - for each file (.te, .fc, ...) we strip out the commented XML
>    - we dump it in a xml/dir/file.extension
>      - we concatenate each file.{fc, te, ...}
>       - we produce a single XML file
>         - we're done for parsing and doing any formatting on top of the
>           source XML file.
> 
> Though It's not the best time to think about it, will give it a further
> look later.
> 
> How it looks to you?
> 

Again - not certain what you mean. We are only processing .if files (interfaces)
to produce a single policy.xml file that has the information from each .if file.

> > Not yet - if you want the parsing code I can release it though.
> 
> It would be good to have all-in-place. With single, separated pieces we
> can't do it, either we have everything clear and well exposed in the
> proper place or we have nothing.
> 

Not to repeat myself, but I'm not certain what you are getting at. Is this a
request for the code to be released?

Thanks,

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> I'm new around this (the ref. policy) and also on the policy itself, I'm
> still not too familiar with it (hadn't enough time to deal with it
> properly), so, I may be wrong, then please give advice and I'll try to
> make it going smooth and straight forward ;).
> 
> Cheers,
> --
> Lorenzo Hernández García-Hierro <lorenzo@gnu.org>
> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.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: ANN: SELinux Reference Policy Release

[Karl MacMillan]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of Colin Walters
> Sent: Wednesday, June 15, 2005 6:36 PM
> To: Christopher J. PeBenito
> Cc: SELinux Mail List
> Subject: Re: ANN: SELinux Reference Policy Release
> 
> On Wed, 2005-06-15 at 17:42 -0400, Christopher J. PeBenito wrote:
> > The first release of the SELinux Reference Policy is now available on
> > Sourceforge from http://serefpolicy.sourceforge.net.
> >
> > This is an experimental release, and definitely is not usable as a
> > drop-in replacement for the current policy, as it can only boot a very
> > limited RHEL4 system.  It is directed towards policy developers, to
> > generate community feedback and discussion.
> 
> Wow.  This looks quite fantastic.  I really, really like the inline
> documentation work.
> 

Thanks - I honestly think that the documentation could become the most important
part of all of this. What we have now in refpolicy is some infrastructure and a
few comments - I can see the documentation growing to the point of being a
general reference for how Linux systems are put together and the security
implications of each access. The knowledge behind each policy decision is the
hard part - not figuring out how to deal with types, attributes, etc.

I'd just like to take this opportunity to solicit help from anyone that is
interested to create some of this documentation. Much of the knowledge is in the
current policies (in the access that is) - it is just hard to get it out
sometimes.

> This work reminds me though; I was thinking a week or so ago about what
> it would be like to write e.g. an Eclipse plugin for policy writing.
> One of the core problems one would run into (and I bet the polgen people
> hit this too) is that it's a nightmare to deal with m4; how do you know
> what macros are available and what they do?  The macros form the real
> policy language, so an IDE would need to understand them.
> 
> You're left with basically hardcoding a list of them, or resorting to
> some evil hack to try to extract the macro names and filter unwanted
> macros.
> 
> The inline documentation in the reference policy is really a form of
> easily parseable metadata that could also be used for this purpose.

We have some Java code lying around that can parse the generated XML if you want
it. We are also working on an eclipse based policy development environment.
Unfortunately I don't think that it will be targeted towards general policy
development any time soon, but you might be able to repurpose some of the code.
The only docs available are at
http://www.selinux-symposium.org/2005/presentations/session6/6-1-wilson.pdf.

> However, it's a bit verbose now.  Let's take an example:
> 
> ########################################
> ## <interface name="selinux_get_enforce_mode">
> ##      <description>
> ##              Allows the caller to get the mode of policy enforcement
> ##              (enforcing or permissive mode).
> ##      </description>
> ##      <parameter name="domain">
> ##              The process type to allow to get the enforcing mode.
> ##      </parameter>
> ## </interface>
> #
> define(`selinux_get_enforce_mode',`
>         gen_require(`$0'_depend)
> 
>         allow $1 security_t:dir { read search getattr };
>         allow $1 security_t:file { getattr read };
> ')
> 
> You have to declare "selinux_get_enforce_mode" twice; it's verbose
> and error-prone.
> 

Agreed - we could actually generate the M4 from the XML (and we are currently
generation some config files in this way). That has some drawbacks - like an
extra compile step.

> What if we actually extended checkpolicy with the notion of "policy
> functions"?  For example, suppose we had syntax like this:
> 

This would have many benefits beyond simpler syntax and has been mentioned a few
times on the list. I would avoid the name function, though. I think it is best
to avoid any suggestion that policy is a programming language with control flow.
Why not interface - though it is not that much better I guess?

Perhaps the largest win for putting these interfaces in the base language is
that loadable module dependencies would be based on the interface rather than
types, making the refpolicy modularity real and allowing third party loadable
modules some chance of successfully linking to various policies.

We can argue about the syntax (and Javadoc vs. C# comment styles), but I agree
that it would be nice to have the infrastructure. It is a bit beyond the scope
of this project, unfortunately. We may be able to devote some resources to this
in the future, but nothing right now.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> # Allows the caller to get the mode of policy enforcement (enforcing or
> # permissive)
> # @param basetype The process type to allow to get the enforcing mode.
> function selinux_get_enforce_mode(domain basetype) {
>   allow basetype security_t:dir { read search getattr };
>   allow basetype security_t:file { getattr read };
> }
> 
> Much nicer, no?
> 
> Ok, so that's a pretty simple function; here's a more complicated
> example, from your apps/gpg.if:
> 
> #######################################
> #
> # Per user domain template for this module
> #
> # gpg_per_userdomain_template(userdomain_prefix)
> #
> define(`gpg_per_userdomain_template',`
>         type $1_gpg_t;
>         domain_type($1_gpg_t)
>         domain_entry_file($1_gpg_t,gpg_exec_t)
>         role $1_r types $1_gpg_t;
> 
>         ...
> 
>         # transition from the userdomain to the derived domain
>         allow $1_t $1_gpg_t:process transition;
>         allow $1_t gpg_exec_t:file rx_file_perms;
>         type_transition $1_t gpg_exec_t:process $1_gpg_t;
> 
>         ...
> 
> Wouldn't it be nice if we could do instead:
> 
> # Define derived domains for GPG from @userdomain
> # @param user The user domain to derive from
> # @param userrole The user role to authorize for GPG
> function gpg_per_userdomain(domain user, role userrole) {
>   derivedtype gpg_t from user
> 
>   domain_type(gpg_t)
>   domain_entry_file(gpg_t, gpg_exec_t)
>   role userrole types gpg_t
> 
>   ...
> 
>   allow user gpg_t:process transition;
>   allow user gpg_exec_t:file rx_file_perms;
>   type_transition user gpg_exec_t:process gpg_t;
> 
>   ...
> }
> 
> The key idea here is that an IDE could actually parse this, and easily
> determine programatically what types and roles are generated by the
> function, without doing hacks like expanding the M4 and parsing that,
> and then guessing.
> 
> Your policy modules work removes one of the major uses of M4 in the
> policy (that being ifdef(`foo.te')), and having policy functions would
> kill the other major use.
> 
> Since you're embarking on rewriting the policy, I thought I'd bring this
> up now.




--
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: ANN: SELinux Reference Policy Release

[KaiGai Kohei]

Hi,

I looked the SELinux Reference Policy lightly.
I prefer such the approach defines explicit interface between modules.

So, I have two propositions. What do you think ?

(1) The part of macros' implementation should be enclosed by tags of <interface>.
     If you intend to manage the reference policy modules by XML database in future,
     managing the whole of interface is better than only description, I think.
--[ e.g ]--------------------------------
########################################
## <interface name="domain_kill_all_domains">
##      <description>
##              Send a kill signal to all domains.
##      </description>
##      <parameter name="domain">
##              The type of the process performing this action.
##      </parameter>
# <implementation>  <-- Add one
define(`domain_kill_all_domains',`
         gen_require(`$0'_depend)

         allow $1 domain:process sigkill;
         allow $1 self:capability kill;
')
          :
#  </implementation> <-- Add one
## </interface>
------------------------------------------

(2) I want to contain lang="XXXX" in the description field for internationalization.
     By default, that should be writen in English, and opitionally taking out the description
     field writen in Japanese and so on will be useful for non-native English user.

# Please set your encoding to UTF-8.
--[ e.g ]--------------------------------
## <description>
##      <p>
##      This module contains basic filesystem types and interfaces. This
##      includes:
##      <ul>
##              <li>The concept of different file types including basic
##              files, mount points, tmp files, etc.</li>
##              <li>Access to groups of files and all files.</li>
##              <li>Types and interfaces for the basic filesystem layout
##              (/, /etc, /tmp, /usr, etc.).</li>
##      </ul>
##      </p>
## </description>
## <description lang="Japanese">
##	<p>
##	このモジュールは以下のファイルシステム用タイプとインターフェースを含みます。
##	<ul>
##		<li>通常ファイル、マウントポイント、一時ファイルなど異なったファイル
##		タイプに対する基本概念</li>
##		<li>ファイルの集合および全体に対するアクセス</li>
##		<li>基本的なファイルシステム構造に対するタイプとインターフェース
##		(/, /etc, /tmp, /usr, etc.).</li>
##	</ul>
##	</p>
## </description>
-----------------------------------------

Thanks,

Christopher J. PeBenito wrote:
> The first release of the SELinux Reference Policy is now available on
> Sourceforge from http://serefpolicy.sourceforge.net.
> 
> This is an experimental release, and definitely is not usable as a
> drop-in replacement for the current policy, as it can only boot a very
> limited RHEL4 system.  It is directed towards policy developers, to
> generate community feedback and discussion.
> 
> Any feedback is welcome.

-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
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: ANN: SELinux Reference Policy Release

[Christopher J. PeBenito]

On Thu, 2005-06-16 at 22:48 +0900, KaiGai Kohei wrote:
> Hi,
> 
> I looked the SELinux Reference Policy lightly.
> I prefer such the approach defines explicit interface between modules.
> 
> So, I have two propositions. What do you think ?
> 
> (1) The part of macros' implementation should be enclosed by tags of <interface>.
>      If you intend to manage the reference policy modules by XML database in future,
>      managing the whole of interface is better than only description, I think.

I don't understand the reason for your suggestion.  The XML is mainly
for documentation purposes.

> (2) I want to contain lang="XXXX" in the description field for internationalization.
>      By default, that should be writen in English, and opitionally taking out the description
>      field writen in Japanese and so on will be useful for non-native English user.

We haven't done much thought about internationalization yet, since its a
challenge to get high quality documentation in English in the first
place.  The attribute would probably be better as lang="xx", e.g.,
lang="jp", so its standardized.  Then in the future tools can easily get
the right language.

> # Please set your encoding to UTF-8.

I don't know much about encodings, but apparently editors (I tried vim
and gedit) will save it as ASCII if there are no non-ASCII characters,
even if you explicitly set UTF-8.

> --[ e.g ]--------------------------------
> ## <description>
> ##      <p>
> ##      This module contains basic filesystem types and interfaces. This
> ##      includes:
> ##      <ul>
> ##              <li>The concept of different file types including basic
> ##              files, mount points, tmp files, etc.</li>
> ##              <li>Access to groups of files and all files.</li>
> ##              <li>Types and interfaces for the basic filesystem layout
> ##              (/, /etc, /tmp, /usr, etc.).</li>
> ##      </ul>
> ##      </p>
> ## </description>
> ## <description lang="Japanese">
> ##	<p>
> ##	このモジュールは以下のファイルシステム用タイプとインターフェースを含みます。
> ##	<ul>
> ##		<li>通常ファイル、マウントポイント、一時ファイルなど異なったファイル
> ##		タイプに対する基本概念</li>
> ##		<li>ファイルの集合および全体に対するアクセス</li>
> ##		<li>基本的なファイルシステム構造に対するタイプとインターフェース
> ##		(/, /etc, /tmp, /usr, etc.).</li>
> ##	</ul>
> ##	</p>
> ## </description>
> -----------------------------------------

-- 
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: ANN: SELinux Reference Policy Release

[KaiGai Kohei]

Hi, Christopher.

> I don't understand the reason for your suggestion.  The XML is mainly
> for documentation purposes.

Hmm, I guessed there are deeply intention on using XML, not only documentation.

> We haven't done much thought about internationalization yet, since its a
> challenge to get high quality documentation in English in the first
> place.  The attribute would probably be better as lang="xx", e.g.,
> lang="jp", so its standardized.  Then in the future tools can easily get
> the right language.

Indeed, internationalized documentation may be early in the day.
But, don't forget to treat other than ASCII characters on this XML engine please.

Thanks, I have hopes in this new policy and approach.
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
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: ANN: SELinux Reference Policy Release

[Valdis.Kletnieks]

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

On Thu, 16 Jun 2005 11:17:23 EDT, "Christopher J. PeBenito" said:

> I don't know much about encodings, but apparently editors (I tried vim
> and gedit) will save it as ASCII if there are no non-ASCII characters,
> even if you explicitly set UTF-8.

That's because UTF-8 with no non-ASCII characters is defined to be the same
as the equivalent ASCII.  You end up using the UTF-8 encoding escapes to encode
non-ASCII characters - no non-ASCII, no escapes, and it's just plain ASCII.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: ANN: SELinux Reference Policy Release

[James Carter]

We support the idea of an SELinux reference policy that is more
structured and easier to customize. This is a great start. 
I'm sure that Tresys would really appreciate any and all feedback.

A community effort to improve this reference policy should greatly
improve the usability of SELinux. If successful, we'd eventually like to
see it, or something like it, to replace our example policy as the focal
point of community policy development. As this happens, we would likely
scale back on the maintenance of our example policy and rely on this
community-developed policy as the reference for SELinux, allowing us to
devote more time to advance the capabilities of SELinux.


On Wed, 2005-06-15 at 17:42 -0400, Christopher J. PeBenito wrote:
> The first release of the SELinux Reference Policy is now available on
> Sourceforge from http://serefpolicy.sourceforge.net.
> 
> This is an experimental release, and definitely is not usable as a
> drop-in replacement for the current policy, as it can only boot a very
> limited RHEL4 system.  It is directed towards policy developers, to
> generate community feedback and discussion.
> 
> Any feedback is welcome.
> 
-- 
James Carter <jwcart2@epoch.ncsc.mil>
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.