By adding this rule, I can assume that every role rule of the form "role
foo_r;" is a declaration and those of the form "role foo_r types bar_t;"
are adding types to an existing role. This makes translating to a
different language easier.
---
policy/modules/services/nx.te | 1 +
1 file changed, 1 insertion(+)
diff --git a/policy/modules/services/nx.te b/policy/modules/services/nx.te
index ebb9582..a3559f2 100644
--- a/policy/modules/services/nx.te
+++ b/policy/modules/services/nx.te
@@ -12,6 +12,7 @@ domain_entry_file(nx_server_t, nx_server_exec_t)
domain_user_exemption_target(nx_server_t)
# we need an extra role because nxserver is called from sshd
# cjp: do we really need this?
+role nx_server_r;
role nx_server_r types nx_server_t;
allow system_r nx_server_r;
--
James Carter <[email protected]>
National Security Agency
On 08/24/10 15:50, James Carter wrote:
> By adding this rule, I can assume that every role rule of the form "role
> foo_r;" is a declaration and those of the form "role foo_r types bar_t;"
> are adding types to an existing role. This makes translating to a
> different language easier.
This is a straightforward one. I don't have a problem with it, though
by requiring a role declaration statement imposes a new requirement that
didn't previously exist.
> ---
> policy/modules/services/nx.te | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/policy/modules/services/nx.te b/policy/modules/services/nx.te
> index ebb9582..a3559f2 100644
> --- a/policy/modules/services/nx.te
> +++ b/policy/modules/services/nx.te
> @@ -12,6 +12,7 @@ domain_entry_file(nx_server_t, nx_server_exec_t)
> domain_user_exemption_target(nx_server_t)
> # we need an extra role because nxserver is called from sshd
> # cjp: do we really need this?
> +role nx_server_r;
> role nx_server_r types nx_server_t;
> allow system_r nx_server_r;
>
>
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Wed, 2010-08-25 at 08:54 -0400, Christopher J. PeBenito wrote:
> On 08/24/10 15:50, James Carter wrote:
> > By adding this rule, I can assume that every role rule of the form "role
> > foo_r;" is a declaration and those of the form "role foo_r types bar_t;"
> > are adding types to an existing role. This makes translating to a
> > different language easier.
>
> This is a straightforward one. I don't have a problem with it, though
> by requiring a role declaration statement imposes a new requirement that
> didn't previously exist.
>
But the fact that multiple role declarations are allowed is a deficiency
of the current policy language. CIL will have a roletype statement
which will eliminate the need for allowing multiple role declarations.
I think that having this extra rule won't harm Refpolicy while being
beneficial for translating Refpolicy to CIL.
> > ---
> > policy/modules/services/nx.te | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/policy/modules/services/nx.te b/policy/modules/services/nx.te
> > index ebb9582..a3559f2 100644
> > --- a/policy/modules/services/nx.te
> > +++ b/policy/modules/services/nx.te
> > @@ -12,6 +12,7 @@ domain_entry_file(nx_server_t, nx_server_exec_t)
> > domain_user_exemption_target(nx_server_t)
> > # we need an extra role because nxserver is called from sshd
> > # cjp: do we really need this?
> > +role nx_server_r;
> > role nx_server_r types nx_server_t;
> > allow system_r nx_server_r;
> >
> >
>
>
--
James Carter <[email protected]>
National Security Agency
On 08/25/10 10:11, James Carter wrote:
> On Wed, 2010-08-25 at 08:54 -0400, Christopher J. PeBenito wrote:
>> On 08/24/10 15:50, James Carter wrote:
>>> By adding this rule, I can assume that every role rule of the form "role
>>> foo_r;" is a declaration and those of the form "role foo_r types bar_t;"
>>> are adding types to an existing role. This makes translating to a
>>> different language easier.
>>
>> This is a straightforward one. I don't have a problem with it, though
>> by requiring a role declaration statement imposes a new requirement that
>> didn't previously exist.
>>
>
> But the fact that multiple role declarations are allowed is a deficiency
> of the current policy language. CIL will have a roletype statement
> which will eliminate the need for allowing multiple role declarations.
>
> I think that having this extra rule won't harm Refpolicy while being
> beneficial for translating Refpolicy to CIL.
Like I said, I don't have a problem with it. I didn't commit it since
you said in your 0 patch email that this patchset was more of a RFC.
>>> ---
>>> policy/modules/services/nx.te | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/policy/modules/services/nx.te b/policy/modules/services/nx.te
>>> index ebb9582..a3559f2 100644
>>> --- a/policy/modules/services/nx.te
>>> +++ b/policy/modules/services/nx.te
>>> @@ -12,6 +12,7 @@ domain_entry_file(nx_server_t, nx_server_exec_t)
>>> domain_user_exemption_target(nx_server_t)
>>> # we need an extra role because nxserver is called from sshd
>>> # cjp: do we really need this?
>>> +role nx_server_r;
>>> role nx_server_r types nx_server_t;
>>> allow system_r nx_server_r;
>>>
>>>
>>
>>
>
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Wed, 2010-08-25 at 11:51 -0400, Christopher J. PeBenito wrote:
> On 08/25/10 10:11, James Carter wrote:
> > On Wed, 2010-08-25 at 08:54 -0400, Christopher J. PeBenito wrote:
> >> On 08/24/10 15:50, James Carter wrote:
> >>> By adding this rule, I can assume that every role rule of the form "role
> >>> foo_r;" is a declaration and those of the form "role foo_r types bar_t;"
> >>> are adding types to an existing role. This makes translating to a
> >>> different language easier.
> >>
> >> This is a straightforward one. I don't have a problem with it, though
> >> by requiring a role declaration statement imposes a new requirement that
> >> didn't previously exist.
> >>
> >
> > But the fact that multiple role declarations are allowed is a deficiency
> > of the current policy language. CIL will have a roletype statement
> > which will eliminate the need for allowing multiple role declarations.
> >
> > I think that having this extra rule won't harm Refpolicy while being
> > beneficial for translating Refpolicy to CIL.
>
> Like I said, I don't have a problem with it. I didn't commit it since
> you said in your 0 patch email that this patchset was more of a RFC.
>
It is. I was not expecting it to be committed at this point. I was
just trying to clarify because it seemed like you were concerned about
imposing a new requirement, but I it looks like I was wrong about that.
> >>> ---
> >>> policy/modules/services/nx.te | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/policy/modules/services/nx.te b/policy/modules/services/nx.te
> >>> index ebb9582..a3559f2 100644
> >>> --- a/policy/modules/services/nx.te
> >>> +++ b/policy/modules/services/nx.te
> >>> @@ -12,6 +12,7 @@ domain_entry_file(nx_server_t, nx_server_exec_t)
> >>> domain_user_exemption_target(nx_server_t)
> >>> # we need an extra role because nxserver is called from sshd
> >>> # cjp: do we really need this?
> >>> +role nx_server_r;
> >>> role nx_server_r types nx_server_t;
> >>> allow system_r nx_server_r;
> >>>
> >>>
> >>
> >>
> >
>
>
--
James Carter <[email protected]>
National Security Agency