rpmlint

rpmlint

[Steve Grubb]

Hi,

Below is a patch that I am thinking about submitting to rpmlint. The main idea
of this patch is to catch places where people might be coding policy knowledge
into scripts. Chcon would require knowing some types in order to work. If the
types ever got changed, the script would break. Can anyone think of other
things we do not want to see in rpm scriplets?

-Steve


diff -ur rpmlint-0.78.orig/PostCheck.py rpmlint-0.78/PostCheck.py
--- rpmlint-0.78.orig/PostCheck.py	2006-11-01 11:13:04.000000000 -0500
+++ rpmlint-0.78/PostCheck.py	2006-11-01 12:26:49.000000000 -0500
@@ -38,6 +38,7 @@
 bracket_regex=re.compile('^[^#]*if.*[^ :\]]\]', re.MULTILINE)
 home_regex=re.compile('[^a-zA-Z]+~/|\${?HOME(\W|$)', re.MULTILINE)
 dangerous_command_regex=re.compile("(^|[;\|`]|&&|$\()\s*(?:\S*/s?bin/)?(cp|mv|ln|tar|rpm|chmod|chown|rm|cpio|install|perl|userdel|groupdel)\s", re.MULTILINE)
+selinux_regex=re.compile("(^|[;\|`]|&&|$\()\s*(?:\S*/s?bin/)?(chcon|runcon)\s", re.MULTILINE)
 single_command_regex=re.compile("^[ \n]*([^ \n]+)[ \n]*$")
 update_menu_regex=re.compile('update-menus', re.MULTILINE)
 tmp_regex=re.compile('\s(/var)?/tmp', re.MULTILINE)
@@ -139,6 +140,10 @@
                 res=dangerous_command_regex.search(script)
                 if res:
                     printWarning(pkg, 'dangerous-command-in-' + tag[2], res.group(2))
+                res=selinux_regex.search(script)
+                if res:
+                    printError(pkg, 'selinux-forbidden-command-in-' + tag[2], res.group(2))
+
                 if update_menu_regex.search(script):
                     menu_error=1
                     for f in files:

--
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: rpmlint

[Joshua Brindle]

Steve Grubb wrote:
> Hi,
>
> Below is a patch that I am thinking about submitting to rpmlint. The main idea
> of this patch is to catch places where people might be coding policy knowledge
> into scripts. Chcon would require knowing some types in order to work. If the
> types ever got changed, the script would break. Can anyone think of other
> things we do not want to see in rpm scriplets?
>
> -Steve
>
>   
calling semanage thusly:

semanage fcontext -a [any arguments here] /some/file

actually any semanage command except *possibly* login and user, and I'm 
not sure they should be there either but someone may have an acceptable 
scenerio.
> diff -ur rpmlint-0.78.orig/PostCheck.py rpmlint-0.78/PostCheck.py
> --- rpmlint-0.78.orig/PostCheck.py	2006-11-01 11:13:04.000000000 -0500
> +++ rpmlint-0.78/PostCheck.py	2006-11-01 12:26:49.000000000 -0500
> @@ -38,6 +38,7 @@
>  bracket_regex=re.compile('^[^#]*if.*[^ :\]]\]', re.MULTILINE)
>  home_regex=re.compile('[^a-zA-Z]+~/|\${?HOME(\W|$)', re.MULTILINE)
>  dangerous_command_regex=re.compile("(^|[;\|`]|&&|$\()\s*(?:\S*/s?bin/)?(cp|mv|ln|tar|rpm|chmod|chown|rm|cpio|install|perl|userdel|groupdel)\s", re.MULTILINE)
> +selinux_regex=re.compile("(^|[;\|`]|&&|$\()\s*(?:\S*/s?bin/)?(chcon|runcon)\s", re.MULTILINE)
>  single_command_regex=re.compile("^[ \n]*([^ \n]+)[ \n]*$")
>  update_menu_regex=re.compile('update-menus', re.MULTILINE)
>  tmp_regex=re.compile('\s(/var)?/tmp', re.MULTILINE)
> @@ -139,6 +140,10 @@
>                  res=dangerous_command_regex.search(script)
>                  if res:
>                      printWarning(pkg, 'dangerous-command-in-' + tag[2], res.group(2))
> +                res=selinux_regex.search(script)
> +                if res:
> +                    printError(pkg, 'selinux-forbidden-command-in-' + tag[2], res.group(2))
> +
>                  if update_menu_regex.search(script):
>                      menu_error=1
>                      for f in files:
>
>   



--
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: rpmlint

[Karl MacMillan]

On Sun, 2006-11-05 at 17:32 -0500, Joshua Brindle wrote:
> Steve Grubb wrote:
> > Hi,
> >
> > Below is a patch that I am thinking about submitting to rpmlint. The main idea
> > of this patch is to catch places where people might be coding policy knowledge
> > into scripts. Chcon would require knowing some types in order to work. If the
> > types ever got changed, the script would break. Can anyone think of other
> > things we do not want to see in rpm scriplets?
> >
> > -Steve
> >
> >   
> calling semanage thusly:
> 
> semanage fcontext -a [any arguments here] /some/file
> 
> actually any semanage command except *possibly* login and user, and I'm 
> not sure they should be there either but someone may have an acceptable 
> scenerio.

If we disallow this then what is the recommended way to allow an
application to ship a labeling only policy? We need to allow
applications to, for example, label a library as textrel_shlib_t without
forcing them to ship a policy module.

What if we added the ability to specify the store by name (i.e.,
semanage -s targeted fcontext -a . . . .). I think it should be
acceptable to make assumptions about what a well know policy contains.
Getting them to use semanage in this way would fix other problems - like
relabeling - without introducing unnecessary policy modules.

Karl


--
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: rpmlint

[Joshua Brindle]

Karl MacMillan wrote:
> On Sun, 2006-11-05 at 17:32 -0500, Joshua Brindle wrote:
>> Steve Grubb wrote:
>>> Hi,
>>>
>>> Below is a patch that I am thinking about submitting to rpmlint. The main idea
>>> of this patch is to catch places where people might be coding policy knowledge
>>> into scripts. Chcon would require knowing some types in order to work. If the
>>> types ever got changed, the script would break. Can anyone think of other
>>> things we do not want to see in rpm scriplets?
>>>
>>> -Steve
>>>
>>>   
>> calling semanage thusly:
>>
>> semanage fcontext -a [any arguments here] /some/file
>>
>> actually any semanage command except *possibly* login and user, and I'm 
>> not sure they should be there either but someone may have an acceptable 
>> scenerio.
> 
> If we disallow this then what is the recommended way to allow an
> application to ship a labeling only policy? We need to allow
> applications to, for example, label a library as textrel_shlib_t without
> forcing them to ship a policy module.
> 

good question, we don't support policy packages without modules now, 
using types directly breaks any kind of encapsulation the policy may 
have had so its non-ideal anyway.

I think this is a more general problem, how does any given app know that 
it needs "some label" that gives it the ability to have textrels in its 
libraries.

> What if we added the ability to specify the store by name (i.e.,
> semanage -s targeted fcontext -a . . . .). I think it should be
> acceptable to make assumptions about what a well know policy contains.
> Getting them to use semanage in this way would fix other problems - like
> relabeling - without introducing unnecessary policy modules.
> 

Store is an arbitrary string that means nothing. Sure this is practical 
but there are version issues (if a type exists in some version X but not 
before that, etc).


--
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: rpmlint

[Karl MacMillan]

On Mon, 2006-11-06 at 11:25 -0500, Joshua Brindle wrote:
> Karl MacMillan wrote:
> > On Sun, 2006-11-05 at 17:32 -0500, Joshua Brindle wrote:
> >> Steve Grubb wrote:
> >>> Hi,
> >>>
> >>> Below is a patch that I am thinking about submitting to rpmlint. The main idea
> >>> of this patch is to catch places where people might be coding policy knowledge
> >>> into scripts. Chcon would require knowing some types in order to work. If the
> >>> types ever got changed, the script would break. Can anyone think of other
> >>> things we do not want to see in rpm scriplets?
> >>>
> >>> -Steve
> >>>
> >>>   
> >> calling semanage thusly:
> >>
> >> semanage fcontext -a [any arguments here] /some/file
> >>
> >> actually any semanage command except *possibly* login and user, and I'm 
> >> not sure they should be there either but someone may have an acceptable 
> >> scenerio.
> > 
> > If we disallow this then what is the recommended way to allow an
> > application to ship a labeling only policy? We need to allow
> > applications to, for example, label a library as textrel_shlib_t without
> > forcing them to ship a policy module.
> > 
> 
> good question, we don't support policy packages without modules now, 
> using types directly breaks any kind of encapsulation the policy may 
> have had so its non-ideal anyway.
> 

Encapsulation at this level is not a goal in my opinion. Encapsulation
is a source construct that helps make the policy _development_
manageable.

It cannot, in any way, help allow implementation changes on a running
system as the identifiers are visible - e.g., types are used on the
filesystem. Users, roles, types, booleans, etc. are well known
identifiers that must be directly referenced to manage a system.

> I think this is a more general problem, how does any given app know that 
> it needs "some label" that gives it the ability to have textrels in its 
> libraries.

I think that the current practice is fine - types have well known
meanings for specific policies.

> > What if we added the ability to specify the store by name (i.e.,
> > semanage -s targeted fcontext -a . . . .). I think it should be
> > acceptable to make assumptions about what a well know policy contains.
> > Getting them to use semanage in this way would fix other problems - like
> > relabeling - without introducing unnecessary policy modules.
> > 
> 
> Store is an arbitrary string that means nothing. Sure this is practical 
> but there are version issues (if a type exists in some version X but not 
> before that, etc).
> 

We are talking about a package targeting a specific system. Targeted for
FC6 is _not_ a random string - it refers to the shipping, default policy
with a known set of fixed types. Can a user install a completely
different "targeted" policy? Of course, but this doesn't happen.

Adding more abstraction here is just going to confuse people - let's go
for the reasonably safe option now that lets people make selinux support
for their packages better without forcing them to jump through too many
hoops. This is Linux not *BSD - let's stop over engineering.

Karl


--
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: rpmlint

[Joshua Brindle]

Karl MacMillan wrote:
> On Mon, 2006-11-06 at 11:25 -0500, Joshua Brindle wrote:
>>
> 
> Encapsulation at this level is not a goal in my opinion. Encapsulation
> is a source construct that helps make the policy _development_
> manageable.
> 

There is already encapsulation at this level: mls level translations.. 
Contexts have always been opaque, how does a package handle mcs, mls, 
targeted and strict policy (this is a real issue since lspp 
configuration doesn't use targeted)

> It cannot, in any way, help allow implementation changes on a running
> system as the identifiers are visible - e.g., types are used on the
> filesystem. Users, roles, types, booleans, etc. are well known
> identifiers that must be directly referenced to manage a system.
> 
>> I think this is a more general problem, how does any given app know that 
>> it needs "some label" that gives it the ability to have textrels in its 
>> libraries.
> 
> I think that the current practice is fine - types have well known
> meanings for specific policies.
> 
>>> What if we added the ability to specify the store by name (i.e.,
>>> semanage -s targeted fcontext -a . . . .). I think it should be
>>> acceptable to make assumptions about what a well know policy contains.
>>> Getting them to use semanage in this way would fix other problems - like
>>> relabeling - without introducing unnecessary policy modules.
>>>
>> Store is an arbitrary string that means nothing. Sure this is practical 
>> but there are version issues (if a type exists in some version X but not 
>> before that, etc).
>>
> 
> We are talking about a package targeting a specific system. Targeted for
> FC6 is _not_ a random string - it refers to the shipping, default policy
> with a known set of fixed types. Can a user install a completely
> different "targeted" policy? Of course, but this doesn't happen.
> 

It does whenever anyone downloads the refpolicy to change which modules 
are built in, this happens, we've seen people request it in irc.

> Adding more abstraction here is just going to confuse people - let's go
> for the reasonably safe option now that lets people make selinux support
> for their packages better without forcing them to jump through too many
> hoops. This is Linux not *BSD - let's stop over engineering.
> 

thats a pot shot... I didn't even suggest any kind of engineering (or 
implementation) whatsoever, just noting potential concerns.


--
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: rpmlint

[Karl MacMillan]

On Mon, 2006-11-06 at 13:13 -0500, Joshua Brindle wrote:
> Karl MacMillan wrote:
> > On Mon, 2006-11-06 at 11:25 -0500, Joshua Brindle wrote:
> >>
> > 
> > Encapsulation at this level is not a goal in my opinion. Encapsulation
> > is a source construct that helps make the policy _development_
> > manageable.
> > 
> 
> There is already encapsulation at this level: mls level translations.. 
> Contexts have always been opaque, how does a package handle mcs, mls, 
> targeted and strict policy (this is a real issue since lspp 
> configuration doesn't use targeted)
> 

Translation != Encapsulation - they have different goals.

If there is not a policy named "targeted" then the operation should
fail. Most packages should treat that as a non-fatal error and let the
default context apply to the files. That is one of the advantages of
splitting the labeling configuration and the application of the default
label.

> > It cannot, in any way, help allow implementation changes on a running
> > system as the identifiers are visible - e.g., types are used on the
> > filesystem. Users, roles, types, booleans, etc. are well known
> > identifiers that must be directly referenced to manage a system.
> > 
> >> I think this is a more general problem, how does any given app know that 
> >> it needs "some label" that gives it the ability to have textrels in its 
> >> libraries.
> > 
> > I think that the current practice is fine - types have well known
> > meanings for specific policies.
> > 
> >>> What if we added the ability to specify the store by name (i.e.,
> >>> semanage -s targeted fcontext -a . . . .). I think it should be
> >>> acceptable to make assumptions about what a well know policy contains.
> >>> Getting them to use semanage in this way would fix other problems - like
> >>> relabeling - without introducing unnecessary policy modules.
> >>>
> >> Store is an arbitrary string that means nothing. Sure this is practical 
> >> but there are version issues (if a type exists in some version X but not 
> >> before that, etc).
> >>
> > 
> > We are talking about a package targeting a specific system. Targeted for
> > FC6 is _not_ a random string - it refers to the shipping, default policy
> > with a known set of fixed types. Can a user install a completely
> > different "targeted" policy? Of course, but this doesn't happen.
> > 
> 
> It does whenever anyone downloads the refpolicy to change which modules 
> are built in, this happens, we've seen people request it in irc.
> 

And would this likely cause breakage in the scenario we are talking
about? Not likely. Also, those users should probably be encouraged to
give the policy a different name. We should enable people to support the
common configuration easily.

> > Adding more abstraction here is just going to confuse people - let's go
> > for the reasonably safe option now that lets people make selinux support
> > for their packages better without forcing them to jump through too many
> > hoops. This is Linux not *BSD - let's stop over engineering.
> > 
> 
> thats a pot shot... I didn't even suggest any kind of engineering (or 
> implementation) whatsoever, just noting potential concerns.
> 

No it's not and only a Nazi would suggest otherwise [1].

Karl

[1] http://en.wikipedia.org/wiki/Godwin's_law


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