Installing new policy

Jeff Johnson n3npq at nc.rr.com
Thu Mar 11 13:56:22 UTC 2004


Russell Coker wrote:

>On Thu, 11 Mar 2004 00:48, Jeff Johnson <n3npq at nc.rr.com> wrote:
>  
>
>>>At the moment rpm_script_t has access to so much that there's no point in
>>>trying to impose any serious restriction on it.
>>>
>>>I suspect that limiting rpm_script_t in any significant way will have
>>>to wait until we have multiple domains for rpm for installing packages
>>>with different signatures.
>>>      
>>>
>>What is the logical connection between
>>    rpm_scriptlet_t has too much access.
>>and
>>    rpm needs multiple domains based on signature "trust".
>>
>>Are there alternatives is what I'm asking.
>>    
>>
>
>Currently we have no control over what can be done by scriptlets, and no 
>control over how it's done.
>
>Some operations can be performed in several ways.  For the packages that we 
>develop we can develop proceedures for how to do these things that require 
>the minimum of access.  For the packages developed by other people they will 
>have to get used to the idea that some of the people who use their packages 
>will not trust scriptlets that they want to run, and therefore they should 
>design them to do the minimum amount of work.  When we start getting that 
>under control we can do something about limiting rpm_script_t.
>
>But at the moment it wants to do everything, and there's little we can do 
>about it without breaking heaps of rpms.  We have enough pain at the moment. 
>
>  
>

Pain and the need for limiting rpm_cript_t well understood, not nudging ;-)

Adding --noscripts --notriggers automagically to each package not signed 
with
trusted signature is an alternative that starts to avoid a lot of 
selinux pain. And,
since very few 3rd party add-on packages are essential to system 
integrity, ther
are few consequences running the scripts after that fact in an entirely 
different
domain of execution.

There are still issues with trojan'ed files in payload, forcing chmod -x 
or chmod 000
might start to limit damage.

So it's the logical connection that leads from
     rpm_script_t has too much access
to
     rpm needs multiple domains based on signature
that I am seeking. selinux is not the only way to limit damage if you 
catch my drift.

But selinux is gonna need a trust proof mark. What is done with the 
proof mark is
different question.

73 de Jeff




More information about the fedora-selinux-list mailing list