trusted vs untrusted packages

trusted vs untrusted packages

[Russell Coker]

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



[1] Names aren't certain yet, just used as an example.  May have 3-4 levels of 
trust too with 3-4 different names.

[2] A relabel of a file system will break this...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: trusted vs untrusted packages

[Carsten Grohmann]

I think the idea of signed rpms is good and useful. 

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

Whom should we trust? The people of the personal web of trust?

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

I'm not sure, about this idea. Because it is necessary to patch rpm 
and the most rpms I've seen creates the file context during the 
post install squence using chcon. On the other side we have more 
secure packages with a (little bit) more complex policy. 

What's about debian packages? Would you sign this too and adapt the 
package tools to handle the file context? 



--
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: trusted vs untrusted packages

[Jeff Johnson]

Carsten Grohmann wrote:

>I think the idea of signed rpms is good and useful. 
>
>  
>
>>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.
>>    
>>
>
>Whom should we trust? The people of the personal web of trust?
>  
>

Defining "trust" is exactly the question. Using fingerprint of package 
signature
to identify "trust" is one, not too surprising, definition for package 
trust.

The deeper issue is factoring trust of package onto trust of contents, both
metadata (which includes scripts to be executed), and payload contents
(i.e. the files themselves).

>  
>
>>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.
>>    
>>
>
>I'm not sure, about this idea. Because it is necessary to patch rpm 
>and the most rpms I've seen creates the file context during the 
>post install squence using chcon. On the other side we have more 
>secure packages with a (little bit) more complex policy. 
>
>What's about debian packages? Would you sign this too and adapt the 
>package tools to handle the file context? 
>
>  
>

I'd suggest looking at a model of a tar archive with a detached 
signature while
developing a trust definition. That model applies to all package management,
and should help clarify the trust model for package management, *.rpm and
*.deb are just archives with certain conventional ornamentation.

73 de Jeff




--
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: trusted vs untrusted packages

[James Morris]

On Tue, 14 Oct 2003, Russell Coker wrote:

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

This should be like enforcing vs. non-enforcing -- you either want all of
your packages signed (and the above would fail) or not (just generate a
warning).


- James
-- 
James Morris
<jmorris@redhat.com>



--
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: trusted vs untrusted packages

[Jeff Johnson]

James Morris wrote:

>On Tue, 14 Oct 2003, Russell Coker wrote:
>
>  
>
>>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).
>>    
>>
>
>This should be like enforcing vs. non-enforcing -- you either want all of
>your packages signed (and the above would fail) or not (just generate a
>warning).
>  
>

Not true. The signature mechanism is different than the trust model. 
Existence of
signature, or constraint of all all packages must be signed, is not an 
adequate definition
of "trust".

73 de Jeff



--
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: trusted vs untrusted packages

[Diyab]

James Morris wrote:
> On Tue, 14 Oct 2003, Russell Coker wrote:
> 
> 
>>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).
> 
> 
> This should be like enforcing vs. non-enforcing -- you either want all of
> your packages signed (and the above would fail) or not (just generate a
> warning).
> 
> 
> - James

How about trust based on the package requiring said untrusted or 
temporarily untrusted package.  For example, you have package abc signed 
by a trusted source.  The package contents have been verified as 
legitimate through something like the package signature. A requirement 
made by the verified abc package says you need package xyz.  The abc 
package also gives you the option to install a public key for the 
required xyz package, which is trusted by the abc package.  Therefore as 
long as package xyz passes the basic signature/validity check then not 
only are the contents valid but they are trusted by someone you trust.

Timothy,

-- 
I put instant coffee in a microwave and almost went back in time.
		-- Steven Wright


--
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: trusted vs untrusted packages

[Robert Potter]

Calls to mind varying degrees of trust, which could be useful technology if
implemented in an AI update scheme.

Rob

-----Original Message-----
From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
Behalf Of Diyab
Sent: Tuesday, October 14, 2003 4:31 PM
To: James Morris
Cc: Russell Coker; SE Linux
Subject: Re: trusted vs untrusted packages


James Morris wrote:
> On Tue, 14 Oct 2003, Russell Coker wrote:
> 
> 
>>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).
> 
> 
> This should be like enforcing vs. non-enforcing -- you either want all 
> of your packages signed (and the above would fail) or not (just 
> generate a warning).
> 
> 
> - James

How about trust based on the package requiring said untrusted or 
temporarily untrusted package.  For example, you have package abc signed 
by a trusted source.  The package contents have been verified as 
legitimate through something like the package signature. A requirement 
made by the verified abc package says you need package xyz.  The abc 
package also gives you the option to install a public key for the 
required xyz package, which is trusted by the abc package.  Therefore as 
long as package xyz passes the basic signature/validity check then not 
only are the contents valid but they are trusted by someone you trust.

Timothy,

-- 
I put instant coffee in a microwave and almost went back in time.
		-- Steven Wright


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




--
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: trusted vs untrusted packages

[Jeff Johnson]

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