Re: checkpolicy is broken (which is not)

Re: checkpolicy is broken (which is not)

[Harry Ciao]

Hi Chris,

I think Dan's case below is a good example, that while
libsepol/checkpolicy/etc upgraded to 2011-07-27 release, people may have
not upgraded(or don't want/need to for the time being) the refpolicy to
the 2011-07-26 release accordingly, then people would run into this problem.

I am wondering if there is a need to add one note in selinux project
wiki page that once upgraded to 2011-07-27 release, at least the
3cbc9727 commit should be cherry-picked to refpolicy, if people still
prefer to older releases.

Thanks,
Harry

Harry Ciao 写道:
> Hi Dan,
>
> This "problem" had been fixed by Chris when the role attribute support
> is merged upstream, by adding one line of "role nx_server_r;" in nx.te.
> Other than that, one extra line of "role $_2;" would have to be added
> before the role-types rule used in the userdom_base_user_template().
>
> The commit id is 3cbc9727, I think you need to cherry-pick it.
>
> The reason is that the original role-type rule no longer used to declare
> a role, but solely focused on associating types with regular role or
> role attribute, whereas the newly added role-attr rule takes care of
> declaring regular role or role attribute, and optionally adding them
> into another role attribute.
>
> Thanks,
> Harry
>
> Daniel J Walsh 写道:
>   
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> This module used to compile and with the latest checkpolicy in upstream
>> it blows up on the role.
>>
>> # make -f /usr/share/selinux/devel/Makefile cat: /selinux/mls: No such
>> file or directory
>> Compiling targeted nx module
>> /usr/bin/checkmodule:  loading policy configuration from tmp/nx.tmp
>> nx.te":15:ERROR 'unknown role nx_server_r' at token ';' on line 3857:
>> role nx_server_r types nx_server_t;
>> # cjp: do we really need this?
>> /usr/bin/checkmodule:  error(s) encountered while parsing configuration
>> make: *** [tmp/nx.mod] Error 1
>>
>>
>> Something to do with the role patch, I believe.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk466m0ACgkQrlYvE4MpobOziACgsLrcXj4EHseXsRCf0fA98t+2
>> hx0An1TPUPcF+z4AAEso7dLgduVW4MNI
>> =xzsa
>> -----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: checkpolicy is broken (which is not)

[Eric Paris]

On 08/04/2011 09:15 PM, Harry Ciao wrote:
> Hi Chris,
> 
> I think Dan's case below is a good example, that while
> libsepol/checkpolicy/etc upgraded to 2011-07-27 release, people may have
> not upgraded(or don't want/need to for the time being) the refpolicy to
> the 2011-07-26 release accordingly, then people would run into this problem.
> 
> I am wondering if there is a need to add one note in selinux project
> wiki page that once upgraded to 2011-07-27 release, at least the
> 3cbc9727 commit should be cherry-picked to refpolicy, if people still
> prefer to older releases.

I don't think we can/should do this.  New userspace should be able to
handle old policy.  You understand this code better than anyone, can you
find a solution such that old modules will still compile and work?

-Eric

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

[refpolicy] checkpolicy is broken (which is not)

[Eric Paris]

On 08/04/2011 09:15 PM, Harry Ciao wrote:
> Hi Chris,
> 
> I think Dan's case below is a good example, that while
> libsepol/checkpolicy/etc upgraded to 2011-07-27 release, people may have
> not upgraded(or don't want/need to for the time being) the refpolicy to
> the 2011-07-26 release accordingly, then people would run into this problem.
> 
> I am wondering if there is a need to add one note in selinux project
> wiki page that once upgraded to 2011-07-27 release, at least the
> 3cbc9727 commit should be cherry-picked to refpolicy, if people still
> prefer to older releases.

I don't think we can/should do this.  New userspace should be able to
handle old policy.  You understand this code better than anyone, can you
find a solution such that old modules will still compile and work?

-Eric

Re: checkpolicy is broken (which is not)

[Harry Ciao]

Hi Eric,

Let me explain more about the background story.

The existing type rule could declare a type, and optionally associate it
with a list of type attributes. So I invented this "role <regular role>
attribute <a list of role attributes>" rule in the same manner to do the
similar things for roles, since I figure this would make refpolicy rules
similar and easy to remember and use.

Now that the above new role-attr rule takes care of declaring roles,
this duty has to be removed from role-type rule in order to avoid
ambiguity, and the role-type rule would be used to only associate types
with roles, which only requires TWO lines of code as in 3cbc9727, since
mostly used roles such as system_r have been declared in kernel.te(in
order to avoid some build failure).

In a word, we could preserve the behavior of role-type rule, but this
would introduce discrepancy between that of role-attr rule and type-attr
rule, considering that getting used to the new toolchain only requires
an easy cherry-pick of only 2 lines of change, would it be that
desirable for us to do so?

Thanks,
Harry



Eric Paris 写道:
> On 08/04/2011 09:15 PM, Harry Ciao wrote:
>   
>> Hi Chris,
>>
>> I think Dan's case below is a good example, that while
>> libsepol/checkpolicy/etc upgraded to 2011-07-27 release, people may have
>> not upgraded(or don't want/need to for the time being) the refpolicy to
>> the 2011-07-26 release accordingly, then people would run into this problem.
>>
>> I am wondering if there is a need to add one note in selinux project
>> wiki page that once upgraded to 2011-07-27 release, at least the
>> 3cbc9727 commit should be cherry-picked to refpolicy, if people still
>> prefer to older releases.
>>     
>
> I don't think we can/should do this.  New userspace should be able to
> handle old policy.  You understand this code better than anyone, can you
> find a solution such that old modules will still compile and work?
>
> -Eric
>
>   


--
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: checkpolicy is broken (which is not)

[Stephen Smalley]

On Fri, 2011-08-05 at 12:19 +0800, Harry Ciao wrote:
> Hi Eric,
> 
> Let me explain more about the background story.
> 
> The existing type rule could declare a type, and optionally associate it
> with a list of type attributes. So I invented this "role <regular role>
> attribute <a list of role attributes>" rule in the same manner to do the
> similar things for roles, since I figure this would make refpolicy rules
> similar and easy to remember and use.
> 
> Now that the above new role-attr rule takes care of declaring roles,
> this duty has to be removed from role-type rule in order to avoid
> ambiguity, and the role-type rule would be used to only associate types
> with roles, which only requires TWO lines of code as in 3cbc9727, since
> mostly used roles such as system_r have been declared in kernel.te(in
> order to avoid some build failure).
> 
> In a word, we could preserve the behavior of role-type rule, but this
> would introduce discrepancy between that of role-attr rule and type-attr
> rule, considering that getting used to the new toolchain only requires
> an easy cherry-pick of only 2 lines of change, would it be that
> desirable for us to do so?

I don't think we should introduce an incompatible policy language change
without very strong reasons.  It is fine to introduce new constructs
like your role...attribute construct, but we shouldn't change the
meaning of role...type statements and thereby render invalid policies
that used to be valid.

-- 
Stephen Smalley
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: checkpolicy is broken (which is not)

[Daniel J Walsh]

On 08/05/2011 08:56 AM, Stephen Smalley wrote:
> On Fri, 2011-08-05 at 12:19 +0800, Harry Ciao wrote:
>> Hi Eric,
>> 
>> Let me explain more about the background story.
>> 
>> The existing type rule could declare a type, and optionally 
>> associate it with a list of type attributes. So I invented this 
>> "role <regular role> attribute <a list of role attributes>" rule
>> in the same manner to do the similar things for roles, since I
>> figure this would make refpolicy rules similar and easy to remember
>> and use.
>> 
>> Now that the above new role-attr rule takes care of declaring 
>> roles, this duty has to be removed from role-type rule in order to 
>> avoid ambiguity, and the role-type rule would be used to only 
>> associate types with roles, which only requires TWO lines of code 
>> as in 3cbc9727, since mostly used roles such as system_r have been 
>> declared in kernel.te(in order to avoid some build failure).
>> 
>> In a word, we could preserve the behavior of role-type rule, but 
>> this would introduce discrepancy between that of role-attr rule
>> and type-attr rule, considering that getting used to the new
>> toolchain only requires an easy cherry-pick of only 2 lines of
>> change, would it be that desirable for us to do so?
> 
> I don't think we should introduce an incompatible policy language 
> change without very strong reasons.  It is fine to introduce new 
> constructs like your role...attribute construct, but we shouldn't 
> change the meaning of role...type statements and thereby render 
> invalid policies that used to be valid.
> 

Well I will say that I thought the old construct did not make sense,
since we have to declare most objects in the lanquage except for roles.

This will help to find problems in the policy also like people doing

role httpd_t types httpd_t;

Which I have seen in the past.

I just got the new toolchain to work with Fedora policy.

--
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: checkpolicy is broken (which is not)

[Stephen Smalley]

On Fri, 2011-08-05 at 08:59 -0400, Daniel J Walsh wrote:
> On 08/05/2011 08:56 AM, Stephen Smalley wrote:
> > On Fri, 2011-08-05 at 12:19 +0800, Harry Ciao wrote:
> >> Hi Eric,
> >> 
> >> Let me explain more about the background story.
> >> 
> >> The existing type rule could declare a type, and optionally 
> >> associate it with a list of type attributes. So I invented this 
> >> "role <regular role> attribute <a list of role attributes>" rule
> >> in the same manner to do the similar things for roles, since I
> >> figure this would make refpolicy rules similar and easy to remember
> >> and use.
> >> 
> >> Now that the above new role-attr rule takes care of declaring 
> >> roles, this duty has to be removed from role-type rule in order to 
> >> avoid ambiguity, and the role-type rule would be used to only 
> >> associate types with roles, which only requires TWO lines of code 
> >> as in 3cbc9727, since mostly used roles such as system_r have been 
> >> declared in kernel.te(in order to avoid some build failure).
> >> 
> >> In a word, we could preserve the behavior of role-type rule, but 
> >> this would introduce discrepancy between that of role-attr rule
> >> and type-attr rule, considering that getting used to the new
> >> toolchain only requires an easy cherry-pick of only 2 lines of
> >> change, would it be that desirable for us to do so?
> > 
> > I don't think we should introduce an incompatible policy language 
> > change without very strong reasons.  It is fine to introduce new 
> > constructs like your role...attribute construct, but we shouldn't 
> > change the meaning of role...type statements and thereby render 
> > invalid policies that used to be valid.
> > 
> 
> Well I will say that I thought the old construct did not make sense,
> since we have to declare most objects in the lanquage except for roles.
> 
> This will help to find problems in the policy also like people doing
> 
> role httpd_t types httpd_t;
> 
> Which I have seen in the past.
> 
> I just got the new toolchain to work with Fedora policy.

So are you saying that you are fine with a newer checkpolicy not
accepting previously valid policy modules?  Such that someone who wants
to upgrade checkpolicy in an existing distribution release (e.g. RHEL6)
can only do so if they also upgrade/modify their policy?

Just to be clear, the role...types statement was in fact the role
declaration in the original language, and you could originally only have
one of them per role.  We later allowed multiple statements per role and
took the union of the types to permit decomposition of the policy into
per-domain source modules.
  
-- 
Stephen Smalley
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: checkpolicy is broken (which is not)

[Daniel J Walsh]

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

On 08/05/2011 09:27 AM, Stephen Smalley wrote:
> On Fri, 2011-08-05 at 08:59 -0400, Daniel J Walsh wrote:
>> On 08/05/2011 08:56 AM, Stephen Smalley wrote:
>>> On Fri, 2011-08-05 at 12:19 +0800, Harry Ciao wrote:
>>>> Hi Eric,
>>>> 
>>>> Let me explain more about the background story.
>>>> 
>>>> The existing type rule could declare a type, and optionally 
>>>> associate it with a list of type attributes. So I invented this
>>>>  "role <regular role> attribute <a list of role attributes>"
>>>> rule in the same manner to do the similar things for roles,
>>>> since I figure this would make refpolicy rules similar and easy
>>>> to remember and use.
>>>> 
>>>> Now that the above new role-attr rule takes care of declaring 
>>>> roles, this duty has to be removed from role-type rule in order
>>>> to avoid ambiguity, and the role-type rule would be used to
>>>> only associate types with roles, which only requires TWO lines
>>>> of code as in 3cbc9727, since mostly used roles such as
>>>> system_r have been declared in kernel.te(in order to avoid some
>>>> build failure).
>>>> 
>>>> In a word, we could preserve the behavior of role-type rule,
>>>> but this would introduce discrepancy between that of role-attr
>>>> rule and type-attr rule, considering that getting used to the
>>>> new toolchain only requires an easy cherry-pick of only 2 lines
>>>> of change, would it be that desirable for us to do so?
>>> 
>>> I don't think we should introduce an incompatible policy language
>>>  change without very strong reasons.  It is fine to introduce new
>>>  constructs like your role...attribute construct, but we
>>> shouldn't change the meaning of role...type statements and
>>> thereby render invalid policies that used to be valid.
>>> 
>> 
>> Well I will say that I thought the old construct did not make
>> sense, since we have to declare most objects in the lanquage except
>> for roles.
>> 
>> This will help to find problems in the policy also like people
>> doing
>> 
>> role httpd_t types httpd_t;
>> 
>> Which I have seen in the past.
>> 
>> I just got the new toolchain to work with Fedora policy.
> 
> So are you saying that you are fine with a newer checkpolicy not 
> accepting previously valid policy modules?  Such that someone who
> wants to upgrade checkpolicy in an existing distribution release
> (e.g. RHEL6) can only do so if they also upgrade/modify their
> policy?

This is a theoretical about something we would never do.  RHEL Releases
are stable and we don't update tool chains, just bug fix.  Maybe third
parties would and then it would be up 2 them to fix their policies.

> 
> Just to be clear, the role...types statement was in fact the role 
> declaration in the original language, and you could originally only
> have one of them per role.  We later allowed multiple statements per
> role and took the union of the types to permit decomposition of the
> policy into per-domain source modules.
> 

I understand, but I think this was a mistake that allows us, the policy
writer to be sloppy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk48AU8ACgkQrlYvE4MpobOCfgCfeBUJylzI4/pHZTA+dtSWcZBw
ulsAn2jO/Ac4LHJajUtgGBUTWT9uWkH7
=Amp6
-----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: checkpolicy is broken (which is not)

[Russell Coker]

On Sat, 6 Aug 2011, Daniel J Walsh <dwalsh@redhat.com> wrote:
> > So are you saying that you are fine with a newer checkpolicy not
> > accepting previously valid policy modules?  Such that someone who
> > wants to upgrade checkpolicy in an existing distribution release
> > (e.g. RHEL6) can only do so if they also upgrade/modify their
> > policy?
> 
> This is a theoretical about something we would never do.  RHEL Releases
> are stable and we don't update tool chains, just bug fix.  Maybe third
> parties would and then it would be up 2 them to fix their policies.

For Debian I want to provide forwards and backwards compatibility as much as 
possible.  Even in situations where I won't support a combination of policy 
and user-space I would like it to not be too difficult for people who want to 
do different things (as some RHEL and CentOS users are apparently doing).

I think that the ideal situation for a Debian upgrade (which can and usually 
is done in stages unlike a RHEL upgrade) is to support either the old policy 
with new user-space or the new policy with the old user-space.  Ideally this 
would also include the ability to rebuild the policy packages from source.

In regard to the "role httpd_t types httpd_t;" corner case, aren't there a 
heap of other corner cases where someone can accidentally write policy that 
doesn't do what they expect?

What about the macros for things like r_file_perms?  How long are we going to 
keep that around?  We've already had a couple of releases with the new 
version.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

--
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: checkpolicy is broken (which is not)

[Joshua Brindle]

Daniel J Walsh wrote:
<snip>>>
>
> Well I will say that I thought the old construct did not make sense,
> since we have to declare most objects in the lanquage except for roles.
>

If SDS hadn't smacked it down I would have deprecated implicit role declaration 
in the original module compiler so it shouldn't be a surprise that I'm fine with 
this change. Refpolicy has always declared roles explicitly (a capability that 
didn't even exist before the module compiler) and if it didn't it was a 
refpolicy bug.

> This will help to find problems in the policy also like people doing
>
> role httpd_t types httpd_t;
>
> Which I have seen in the past.
>
> I just got the new toolchain to work with Fedora policy.
>

--
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: checkpolicy is broken (which is not)

[Stephen Smalley]

On Sat, 2011-08-06 at 01:30 +1000, Russell Coker wrote:
> I think that the ideal situation for a Debian upgrade (which can and usually 
> is done in stages unlike a RHEL upgrade) is to support either the old policy 
> with new user-space or the new policy with the old user-space.  Ideally this 
> would also include the ability to rebuild the policy packages from source.

I'm not sure how you could support the latter, as newer policy sources
will use the language features supported by the latest checkpolicy, and
thus often won't be compilable by an older checkpolicy.  The former is
possible, but requires us to preserve the present ambiguity between
declaring a role and adding types to an existing role.

> In regard to the "role httpd_t types httpd_t;" corner case, aren't there a 
> heap of other corner cases where someone can accidentally write policy that 
> doesn't do what they expect?

Certainly, but I think the notion was to provide the same level of
compile-time checking of roles as we presently get for types.  Users
would be the last remaining holdout at that point; like roles, we
allowed multiple declarations when we decomposed the policy into
per-domain source modules, introducing ambiguity between declaration and
use.  We had a somewhat similar issue for type attributes, where they
were originally defined implicitly on first use in a type declaration,
and then later we added explicit attribute declarations and required
their use to avoid similar mistakes.

> What about the macros for things like r_file_perms?  How long are we going to 
> keep that around?  We've already had a couple of releases with the new 
> version.

-- 
Stephen Smalley
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: checkpolicy is broken (which is not)

[James Carter]

On Fri, 2011-08-05 at 08:56 -0400, Stephen Smalley wrote:
> On Fri, 2011-08-05 at 12:19 +0800, Harry Ciao wrote:
> > Hi Eric,
> > 
> > Let me explain more about the background story.
> > 
> > The existing type rule could declare a type, and optionally associate it
> > with a list of type attributes. So I invented this "role <regular role>
> > attribute <a list of role attributes>" rule in the same manner to do the
> > similar things for roles, since I figure this would make refpolicy rules
> > similar and easy to remember and use.
> > 
> > Now that the above new role-attr rule takes care of declaring roles,
> > this duty has to be removed from role-type rule in order to avoid
> > ambiguity, and the role-type rule would be used to only associate types
> > with roles, which only requires TWO lines of code as in 3cbc9727, since
> > mostly used roles such as system_r have been declared in kernel.te(in
> > order to avoid some build failure).
> > 
> > In a word, we could preserve the behavior of role-type rule, but this
> > would introduce discrepancy between that of role-attr rule and type-attr
> > rule, considering that getting used to the new toolchain only requires
> > an easy cherry-pick of only 2 lines of change, would it be that
> > desirable for us to do so?
> 
> I don't think we should introduce an incompatible policy language change
> without very strong reasons.  It is fine to introduce new constructs
> like your role...attribute construct, but we shouldn't change the
> meaning of role...type statements and thereby render invalid policies
> that used to be valid.
> 

In the up and coming CIL compiler, declaration and use are always
separate, so user, role, and type rules are only used to declare. There
are typealias, typeattribute, and other such rules to define
associations. For a role there is a separate roletype rule to associate
a type with a role.

So if roletype and roleattribute rules were created for the current
toolchain, the current role rule would not have to be changed. Newer
policies could use the role rule only to declare a role, but it could
still be used in the old way for backwards compatibility.

-- 
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: checkpolicy is broken (which is not)

[Eric Paris]

On 08/05/2011 12:58 PM, James Carter wrote:
> On Fri, 2011-08-05 at 08:56 -0400, Stephen Smalley wrote:

>> I don't think we should introduce an incompatible policy language change
>> without very strong reasons.  It is fine to introduce new constructs
>> like your role...attribute construct, but we shouldn't change the
>> meaning of role...type statements and thereby render invalid policies
>> that used to be valid.
>>
> 
> In the up and coming CIL compiler, declaration and use are always
> separate, so user, role, and type rules are only used to declare. There
> are typealias, typeattribute, and other such rules to define
> associations. For a role there is a separate roletype rule to associate
> a type with a role.
> 
> So if roletype and roleattribute rules were created for the current
> toolchain, the current role rule would not have to be changed. Newer
> policies could use the role rule only to declare a role, but it could
> still be used in the old way for backwards compatibility.

Sounds to me like there is enough interest in compatiblity that we
should make the current toolchain continue to allow the old role X type
Y rules to also be a declaration.  In the new CIL toolchain we will make
the syntax more strict and require better policy definitions.  Harry, is
this patch something you can take a moment and write?  Thanks!

-Eric

--
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: checkpolicy is broken (which is not)

[Joshua Brindle]

Eric Paris wrote:
> On 08/05/2011 12:58 PM, James Carter wrote:
>> On Fri, 2011-08-05 at 08:56 -0400, Stephen Smalley wrote:
>
>>> I don't think we should introduce an incompatible policy language change
>>> without very strong reasons.  It is fine to introduce new constructs
>>> like your role...attribute construct, but we shouldn't change the
>>> meaning of role...type statements and thereby render invalid policies
>>> that used to be valid.
>>>
>> In the up and coming CIL compiler, declaration and use are always
>> separate, so user, role, and type rules are only used to declare. There
>> are typealias, typeattribute, and other such rules to define
>> associations. For a role there is a separate roletype rule to associate
>> a type with a role.
>>
>> So if roletype and roleattribute rules were created for the current
>> toolchain, the current role rule would not have to be changed. Newer
>> policies could use the role rule only to declare a role, but it could
>> still be used in the old way for backwards compatibility.
>
> Sounds to me like there is enough interest in compatiblity that we
> should make the current toolchain continue to allow the old role X type
> Y rules to also be a declaration.  In the new CIL toolchain we will make
> the syntax more strict and require better policy definitions.  Harry, is
> this patch something you can take a moment and write?  Thanks!
>

Wait, what interest? From my count Dan doesn't care, Jim doesn't care, I 
am for breaking it and SDS's latest email seems to be against implicit 
declarations (and declaration ambiguity).

--
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: checkpolicy is broken (which is not)

[Harry Ciao]

Hi Dan,

Daniel J Walsh 写道:
> On 08/05/2011 08:56 AM, Stephen Smalley wrote:
>   
>> On Fri, 2011-08-05 at 12:19 +0800, Harry Ciao wrote:
>>     
>>> Hi Eric,
>>>
>>> Let me explain more about the background story.
>>>
>>> The existing type rule could declare a type, and optionally 
>>> associate it with a list of type attributes. So I invented this 
>>> "role <regular role> attribute <a list of role attributes>" rule
>>> in the same manner to do the similar things for roles, since I
>>> figure this would make refpolicy rules similar and easy to remember
>>> and use.
>>>
>>> Now that the above new role-attr rule takes care of declaring 
>>> roles, this duty has to be removed from role-type rule in order to 
>>> avoid ambiguity, and the role-type rule would be used to only 
>>> associate types with roles, which only requires TWO lines of code 
>>> as in 3cbc9727, since mostly used roles such as system_r have been 
>>> declared in kernel.te(in order to avoid some build failure).
>>>
>>> In a word, we could preserve the behavior of role-type rule, but 
>>> this would introduce discrepancy between that of role-attr rule
>>> and type-attr rule, considering that getting used to the new
>>> toolchain only requires an easy cherry-pick of only 2 lines of
>>> change, would it be that desirable for us to do so?
>>>       
>> I don't think we should introduce an incompatible policy language 
>> change without very strong reasons.  It is fine to introduce new 
>> constructs like your role...attribute construct, but we shouldn't 
>> change the meaning of role...type statements and thereby render 
>> invalid policies that used to be valid.
>>
>>     
>
> Well I will say that I thought the old construct did not make sense,
> since we have to declare most objects in the lanquage except for roles.
>
> This will help to find problems in the policy also like people doing
>
> role httpd_t types httpd_t;
>
> Which I have seen in the past.
>
>   
During developing role-attribute patchset, I'd discovered two similar
mistakes after removing implicit role declaration from role-type rule:

1. mozilla_run_plugin(mozilla_t, $2)
2. seutil_run_semanage(lsassd_t, lsassd_t)

Both of them had been fixed in the latest refpolicy.

If people prefer to older refpolicy with the latest toolchain, I would
suggest them to cherry-pick fixes for above two obvious mistakes.

> I just got the new toolchain to work with Fedora policy.
>
>   
Thanks! Any further issue with the role-attribute rules, just let me know!

Cheers,
Harry


--
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: checkpolicy is broken (which is not)

[HarryCiao]

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


Hi Stephen,

> Subject: Re: checkpolicy is broken (which is not)
> From: sds@tycho.nsa.gov
> To: russell@coker.com.au
> CC: dwalsh@redhat.com; selinux@tycho.nsa.gov
> Date: Fri, 5 Aug 2011 12:20:59 -0400
> 
> On Sat, 2011-08-06 at 01:30 +1000, Russell Coker wrote:
> > I think that the ideal situation for a Debian upgrade (which can and usually 
> > is done in stages unlike a RHEL upgrade) is to support either the old policy 
> > with new user-space or the new policy with the old user-space.  Ideally this 
> > would also include the ability to rebuild the policy packages from source.
> 
> I'm not sure how you could support the latter, as newer policy sources
> will use the language features supported by the latest checkpolicy, and
> thus often won't be compilable by an older checkpolicy.  The former is
> possible, but requires us to preserve the present ambiguity between
> declaring a role and adding types to an existing role.
> 
> > In regard to the "role httpd_t types httpd_t;" corner case, aren't there a 
> > heap of other corner cases where someone can accidentally write policy that 
> > doesn't do what they expect?
> 
> Certainly, but I think the notion was to provide the same level of
> compile-time checking of roles as we presently get for types.  Users
> would be the last remaining holdout at that point; like roles, we
> allowed multiple declarations when we decomposed the policy into
> per-domain source modules, introducing ambiguity between declaration and
> use.  We had a somewhat similar issue for type attributes, where they
> were originally defined implicitly on first use in a type declaration,
> and then later we added explicit attribute declarations and required
> their use to avoid similar mistakes.
> 

I have not understood this question as deep as others :-P

As for removing above "ambiguity between declaration and use", so it would be desirable to remove the association between a regular type and type attributes in the current type-attribute rule, and shrink it to some "type" rule only for type declaration, and request policy writers to setup the association explicitly via the typeattribute rule. 

Also we should handle roles in a similar way: use some "role" rule solely for role declaration and "attribute_role" rule for role attribute declaration, then "roleattribute" rule for setting up their associations.

Is that right?

Also this would introduce significant change to the original type-attribute rule, how would it be easier for the community to accept such change?

Thanks!

Best regards,
Harry


> > What about the macros for things like r_file_perms?  How long are we going to 
> > keep that around?  We've already had a couple of releases with the new 
> > version.
> 
> -- 
> Stephen Smalley
> 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.
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 3616 bytes --]

RE: checkpolicy is broken (which is not)

[Stephen Smalley]

On Mon, 2011-08-08 at 06:41 +0000, HarryCiao wrote:
> Hi Stephen,
> 
> As for removing above "ambiguity between declaration and use", so it
> would be desirable to remove the association between a regular type
> and type attributes in the current type-attribute rule, and shrink it
> to some "type" rule only for type declaration, and request policy
> writers to setup the association explicitly via the typeattribute
> rule. 
> 
> Also we should handle roles in a similar way: use some "role" rule
> solely for role declaration and "attribute_role" rule for role
> attribute declaration, then "roleattribute" rule for setting up their
> associations.
> 
> Is that right?
> 
> Also this would introduce significant change to the original
> type-attribute rule, how would it be easier for the community to
> accept such change?

I'm not asking for any further changes to the language, just explaining
the analogy to the type-related statements.

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