* Re: checkpolicy is broken (which is not)
2011-08-05 12:59 ` Daniel J Walsh
@ 2011-08-05 13:27 ` Stephen Smalley
2011-08-05 14:42 ` Daniel J Walsh
2011-08-05 15:45 ` Joshua Brindle
2011-08-08 5:38 ` Harry Ciao
2 siblings, 1 reply; 17+ messages in thread
From: Stephen Smalley @ 2011-08-05 13:27 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: qingtao.cao, Eric Paris, Christopher J. PeBenito, SELinux
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: checkpolicy is broken (which is not)
2011-08-05 13:27 ` Stephen Smalley
@ 2011-08-05 14:42 ` Daniel J Walsh
2011-08-05 15:30 ` Russell Coker
0 siblings, 1 reply; 17+ messages in thread
From: Daniel J Walsh @ 2011-08-05 14:42 UTC (permalink / raw)
To: Stephen Smalley; +Cc: qingtao.cao, Eric Paris, Christopher J. PeBenito, SELinux
-----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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: checkpolicy is broken (which is not)
2011-08-05 14:42 ` Daniel J Walsh
@ 2011-08-05 15:30 ` Russell Coker
2011-08-05 16:20 ` Stephen Smalley
0 siblings, 1 reply; 17+ messages in thread
From: Russell Coker @ 2011-08-05 15:30 UTC (permalink / raw)
To: Daniel J Walsh, SELinux; +Cc: Stephen Smalley
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: checkpolicy is broken (which is not)
2011-08-05 15:30 ` Russell Coker
@ 2011-08-05 16:20 ` Stephen Smalley
2011-08-08 6:41 ` HarryCiao
0 siblings, 1 reply; 17+ messages in thread
From: Stephen Smalley @ 2011-08-05 16:20 UTC (permalink / raw)
To: russell; +Cc: Daniel J Walsh, SELinux
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: checkpolicy is broken (which is not)
2011-08-05 16:20 ` Stephen Smalley
@ 2011-08-08 6:41 ` HarryCiao
2011-08-08 12:01 ` Stephen Smalley
0 siblings, 1 reply; 17+ messages in thread
From: HarryCiao @ 2011-08-08 6:41 UTC (permalink / raw)
To: sds, russell; +Cc: dwalsh, selinux
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: checkpolicy is broken (which is not)
2011-08-08 6:41 ` HarryCiao
@ 2011-08-08 12:01 ` Stephen Smalley
0 siblings, 0 replies; 17+ messages in thread
From: Stephen Smalley @ 2011-08-08 12:01 UTC (permalink / raw)
To: HarryCiao; +Cc: russell, dwalsh, selinux
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: checkpolicy is broken (which is not)
2011-08-05 12:59 ` Daniel J Walsh
2011-08-05 13:27 ` Stephen Smalley
@ 2011-08-05 15:45 ` Joshua Brindle
2011-08-08 5:38 ` Harry Ciao
2 siblings, 0 replies; 17+ messages in thread
From: Joshua Brindle @ 2011-08-05 15:45 UTC (permalink / raw)
To: Daniel J Walsh
Cc: Stephen Smalley, qingtao.cao, Eric Paris,
Christopher J. PeBenito, SELinux
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: checkpolicy is broken (which is not)
2011-08-05 12:59 ` Daniel J Walsh
2011-08-05 13:27 ` Stephen Smalley
2011-08-05 15:45 ` Joshua Brindle
@ 2011-08-08 5:38 ` Harry Ciao
2 siblings, 0 replies; 17+ messages in thread
From: Harry Ciao @ 2011-08-08 5:38 UTC (permalink / raw)
To: Daniel J Walsh
Cc: Stephen Smalley, Eric Paris, Christopher J. PeBenito, SELinux
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.
^ permalink raw reply [flat|nested] 17+ messages in thread