Re: checkpolicy is broken (which is not)

[Daniel J Walsh <dwalsh@redhat.com>]

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