* trusted vs untrusted packages
@ 2003-10-14 1:07 Russell Coker
2003-10-14 11:33 ` Carsten Grohmann
2003-10-14 12:06 ` James Morris
0 siblings, 2 replies; 8+ messages in thread
From: Russell Coker @ 2003-10-14 1:07 UTC (permalink / raw)
To: SE Linux
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: trusted vs untrusted packages
2003-10-14 1:07 trusted vs untrusted packages Russell Coker
@ 2003-10-14 11:33 ` Carsten Grohmann
2003-10-14 17:23 ` Jeff Johnson
2003-10-14 12:06 ` James Morris
1 sibling, 1 reply; 8+ messages in thread
From: Carsten Grohmann @ 2003-10-14 11:33 UTC (permalink / raw)
To: russell, SE Linux
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: trusted vs untrusted packages
2003-10-14 1:07 trusted vs untrusted packages Russell Coker
2003-10-14 11:33 ` Carsten Grohmann
@ 2003-10-14 12:06 ` James Morris
2003-10-14 17:26 ` Jeff Johnson
2003-10-14 23:31 ` Diyab
1 sibling, 2 replies; 8+ messages in thread
From: James Morris @ 2003-10-14 12:06 UTC (permalink / raw)
To: Russell Coker; +Cc: SE Linux
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: trusted vs untrusted packages
2003-10-14 11:33 ` Carsten Grohmann
@ 2003-10-14 17:23 ` Jeff Johnson
0 siblings, 0 replies; 8+ messages in thread
From: Jeff Johnson @ 2003-10-14 17:23 UTC (permalink / raw)
To: SE Linux
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: trusted vs untrusted packages
2003-10-14 12:06 ` James Morris
@ 2003-10-14 17:26 ` Jeff Johnson
2003-10-14 23:31 ` Diyab
1 sibling, 0 replies; 8+ messages in thread
From: Jeff Johnson @ 2003-10-14 17:26 UTC (permalink / raw)
To: SE Linux
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: trusted vs untrusted packages
2003-10-14 12:06 ` James Morris
2003-10-14 17:26 ` Jeff Johnson
@ 2003-10-14 23:31 ` Diyab
2003-10-15 0:20 ` Robert Potter
1 sibling, 1 reply; 8+ messages in thread
From: Diyab @ 2003-10-14 23:31 UTC (permalink / raw)
To: James Morris; +Cc: Russell Coker, SE Linux
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: trusted vs untrusted packages
2003-10-14 23:31 ` Diyab
@ 2003-10-15 0:20 ` Robert Potter
0 siblings, 0 replies; 8+ messages in thread
From: Robert Potter @ 2003-10-15 0:20 UTC (permalink / raw)
To: 'SE Linux'
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: trusted vs untrusted packages
@ 2003-10-14 16:47 Jeff Johnson
0 siblings, 0 replies; 8+ messages in thread
From: Jeff Johnson @ 2003-10-14 16:47 UTC (permalink / raw)
To: SE Linux
[-- 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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-10-15 0:20 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-14 1:07 trusted vs untrusted packages Russell Coker
2003-10-14 11:33 ` Carsten Grohmann
2003-10-14 17:23 ` Jeff Johnson
2003-10-14 12:06 ` James Morris
2003-10-14 17:26 ` Jeff Johnson
2003-10-14 23:31 ` Diyab
2003-10-15 0:20 ` Robert Potter
2003-10-14 16:47 Jeff Johnson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.