Re: trusted vs untrusted packages

[Jeff Johnson <n3npq@nc.rr.com>]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Re: trusted vs untrusted packages --]
[-- Type: message/rfc822, Size: 2556 bytes --]

From: Jeff Johnson <n3npq@nc.rr.com>
To: russell@coker.com.au
Subject: Re: trusted vs untrusted packages
Date: Tue, 14 Oct 2003 08:28:48 -0400
Message-ID: <3F8BEC00.9070909@nc.rr.com>

Russell Coker wrote:

>We have been having some IRC discussions about trusted RPMs.  But please note 
>that I am not an expert on RPM, so I'll probably get terminology wrong (at 
>least).  Please correct any errors and CC the list for the benefit of all 
>readers.
>
>RPMs can be signed or unsigned.  If an RPM is signed by a trusted organization 
>then there should be some differences in an SE Linux install than if it is 
>not signed or if we don't trust the signer.
>
>One idea is to have signed packages be installed by rpm running as rpm_t and 
>unsigned packages be installed by rpm running as rpm_unsigned_t [1].  So for 
>example we could allow rpm_unsigned_t to install files in /sbin as 
>sbin_unsigned_t and in /bin as bin_unsigned_t [2].  Then a program installed 
>from an untrusted package can't be run from sysadm_t, and if it's run from 
>other trusted domains (EG part of the mail server) then it could trigger an 
>automatic domain transition to an appropriate domain.
>
>Now this raises some interesting issues.  If a signed package has a program 
>which relies on some other program (and has a dependency), what happens if 
>the dependency is satisfied by an unsigned package?  Installing the unsigned 
>package may not result in the system being fully functional (execution of the 
>file in question may be denied).
>  
>

The key phrase is "relies on some other program" and the type of 
relationship.

Clearly, a trusted executable cannot invoke an untrusted executable 
without losing its
trustedness.

The answer is far less clear when the relationship is a dependency 
between signed and
unsigned packages, and the files contained within.

Which indicates to me that decicisions on whether to permit file exec 
based on package
signatures needs to be reworked. An executable (or library or script) 
might  lose some
aspect of "trust" because the executable came from an unsigned package, 
but a stronger
definition of "trust" must be associated with the file itself, not the 
cellophane from which
it came.

73 de Jeff