RPM security (a newbie question)

["Stanisław T. Findeisen"]

What does the process of installing new RPM package look like? There are 
some commands that such package is allowed to execute, right?

What are RPMs allowed to do, and what is forbidden? Is there any control 
layer at all in the package manager, or is the control (e.g., during 
package install) simply transferred to RPM-package-provided script??

Also what's the difference between "Everything" and "Fedora" dirs
in 
Fedora package tree?

I wonder how easy it is to create a rootkit/trojan horse/whatever and 
get it loaded on Fedora users' computers.

Thanks!

STF

=======================================================================
http://eisenbits.homelinux.net/~stf/
OpenPGP: 9D25 3D89 75F1 DF1D F434  25D7 E87F A1B9 B80F 8062
=======================================================================

[Todd Zullinger]

"Stanisław T. Findeisen" wrote:
>  What does the process of installing new RPM package look like? There
>  are some commands that such package is allowed to execute, right? 
By policy, there are things that rpm scriptlets should not do.  But if
you created an rpm which had a %post section containing rm -rf /, rpm
would run it AFAIK.

>  Also what's the difference between "Everything" and
> "Fedora" dirs in
>  Fedora package tree? 
The Fedora dir contains just what is included on the DVD media.  The
Everything dir contains all of the packages available.  Everything is
a superset of Fedora.

>  I wonder how easy it is to create a rootkit/trojan horse/whatever
>  and get it loaded on Fedora users' computers. 
You would need to create a trojan package and get it onto the mirrors,
signed by the Fedora package signing key for a particular release.
This is not an easy task, as the keys are held pretty tightly, with
very limited access (if a handful of people can sign packages, I'd be
surprised).

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An election is coming. Universal peace is declared and the foxes have
a sincere interest in prolonging the lives of the poultry.
    -- T.S. Eliot

["Stanisław T. Findeisen"]

Todd Zullinger wrote:
>  By policy, there are things that rpm scriptlets should not do.  But
> if
>  you created an rpm which had a %post section containing rm -rf /, rpm
>  would run it AFAIK. 
Oh! 8-O

> > I wonder how easy it is to create a rootkit/trojan
> horse/whatever
> > and get it loaded on Fedora users' computers.
>  
>  You would need to create a trojan package and get it onto the mirrors,
>  signed by the Fedora package signing key for a particular release.
>  This is not an easy task 
Really? Have you seen a list telling you who reviewed which package 
before it got signed with Fedora key?

Probably there are lots of packages reviewed by their authors only?

STF

=======================================================================
http://eisenbits.homelinux.net/~stf/
OpenPGP: 9D25 3D89 75F1 DF1D F434  25D7 E87F A1B9 B80F 8062
=======================================================================

[Rahul Sundaram]

Stanisław T. Findeisen wrote:

>  Really? Have you seen a list telling you who reviewed which package
>  before it got signed with Fedora key?
>  
>  Probably there are lots of packages reviewed by their authors only? 
Review and signing are two different processes. Every single new package
has to go through a review process as outlined in

http://fedoraproject.org/wiki/Packaging/ReviewGuidelines

Signing a package is done by a small number of people in the release
engineering team and they do that manually before pushing it into the
repositories.

Rahul

["Stanisław T. Findeisen"]

Rahul Sundaram wrote:
> > Probably there are lots of packages reviewed by their authors
> only?
>  
>  Review and signing are two different processes. Every single new package
>  has to go through a review process as outlined in
>  
>  http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
>  
>  Signing a package is done by a small number of people in the release
>  engineering team and they do that manually before pushing it into the
>  repositories. 
Well, it looks that those "review guidelines" cover mostly 
administrative/legal issues. It looks that no one cares about the source 
code.

So it looks that it's quite possible to have a lot of trojan 
horses/rootkits/whatever in the distribution tree.

To get rid of it, we would have to review the source code.

STF

=======================================================================
http://eisenbits.homelinux.net/~stf/
OpenPGP: 9D25 3D89 75F1 DF1D F434  25D7 E87F A1B9 B80F 8062
=======================================================================

["Stanisław T. Findeisen"]

Rahul Sundaram wrote:
>  You missed that the review guidelines has a source check as well.
> Read
>  it in detail. 
Where's that, sorry?

STF

=======================================================================
http://eisenbits.homelinux.net/~stf/
OpenPGP: 9D25 3D89 75F1 DF1D F434  25D7 E87F A1B9 B80F 8062
=======================================================================

[Rahul Sundaram]

Stanisław T. Findeisen wrote:
>  Rahul Sundaram wrote:
> >> Probably there are lots of packages reviewed by their authors only?
> >
> > Review and signing are two different processes. Every single new package
> > has to go through a review process as outlined in
> >
> > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
> >
> > Signing a package is done by a small number of people in the release
> > engineering team and they do that manually before pushing it into the
> > repositories.
>  
>  Well, it looks that those "review guidelines" cover mostly
>  administrative/legal issues. It looks that no one cares about the source
>  code. 
You missed that the review guidelines has a source check as well. Read
it in detail.

Rahul

[Todd Zullinger]

Rahul Sundaram wrote:
>  Stanisław T. Findeisen wrote:
> > Well, it looks that those "review guidelines" cover mostly
> > administrative/legal issues. It looks that no one cares about the
> > source code.
>
>  You missed that the review guidelines has a source check as well.
>  Read it in detail. 
While the review guidelines do make sure that the source code matches
upstream¹, that doesn't ensure that upstream doesn't have backdoors,
holes, malicious content, etc.

The only solution for that is more eyes loooking over the code that
makes up the OS.  What mitigates that is knowing that if upstream has
such code, it may be noticed not only by Fedora, but by any other
distro or user.  And that would surely become known rather quickly.

One big advantage that free software has is that anyone is free to
look over the code.  The more people that use that freedom, the better
off we'll all be.

¹ https://fedoraproject.org/wiki/Packaging:ReviewGuidelines includes:
  MUST: The sources used to build the package must match the upstream
  source, as provided in the spec URL.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I always keep a supply of stimulant handy in case I see a snake -
which I also keep handy.
    -- W. C. Fields

[Rahul Sundaram]

Todd Zullinger wrote:
>  Rahul Sundaram wrote:
> > Stanisław T. Findeisen wrote:
> >> Well, it looks that those "review guidelines" cover mostly
> >> administrative/legal issues. It looks that no one cares about the
> >> source code.
> > You missed that the review guidelines has a source check as well.
> > Read it in detail.
>  
>  While the review guidelines do make sure that the source code matches
>  upstream¹, that doesn't ensure that upstream doesn't have backdoors,
>  holes, malicious content, etc. 
That's a totally different question IMO. We at the distribution level
can only check whether there is a packaging level attempt at introducing
a security hole. Doing a complete security audit of all the code that is
being included is not feasible at all at the distribution level. This
btw, has nothing to do with RPM or any other packaging method. All
distributions work on the principle that upstream projects are
responsible at the code level for their own security. We can add things
like compiler options and firewalls but that doesn't prevent a upstream
security hole from being exploited, whether introduced accidentally or not.

Rahul

[Todd Zullinger]

Rahul Sundaram wrote:
>  Todd Zullinger wrote:
> > While the review guidelines do make sure that the source code
> > matches upstream¹, that doesn't ensure that upstream doesn't have
> > backdoors, holes, malicious content, etc.
>
>  That's a totally different question IMO. 
No doubt.  I was only mentioning this because I _think_ it is what
Stanisław was getting at.

>  We at the distribution level can only check whether there is a
>  packaging level attempt at introducing a security hole. Doing a
>  complete security audit of all the code that is being included is
>  not feasible at all at the distribution level. This btw, has nothing
>  to do with RPM or any other packaging method. All distributions work
>  on the principle that upstream projects are responsible at the code
>  level for their own security. We can add things like compiler
>  options and firewalls but that doesn't prevent a upstream security
>  hole from being exploited, whether introduced accidentally or not. 
I fully agree. :)

And, of course, on top of compiler options and firewalls, SELinux is
one more layer that is added to protect against problems in upstream
code.  If upstream code has some hole that tries to mail off
/etc/passwd somewhere, this is very likely to be denied by SELinux.
And when someone reports the denial, Dan, Miroslav, and the other
SELinux maintainers aren't too likely to allow it without asking what
good reason the upstream code would have to take such an action.

But as you say, it's not possible for any distro to find and fix every
security hole, just as it's not possible to find and fix every bug.
More help is always welcome.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I always keep a supply of stimulant handy in case I see a snake -
which I also keep handy.
    -- W. C. Fields

["Stanisław T. Findeisen"]

Rahul Sundaram wrote:
> > While the review guidelines do make sure that the source code
> matches
> > upstream¹, that doesn't ensure that upstream doesn't have backdoors,
> > holes, malicious content, etc.
>  
>  That's a totally different question IMO. We at the distribution level
>  can only check whether there is a packaging level attempt at introducing
>  a security hole. Doing a complete security audit of all the code that is
>  being included is not feasible at all at the distribution level. This
>  btw, has nothing to do with RPM or any other packaging method. All
>  distributions work on the principle that upstream projects are
>  responsible at the code level for their own security. We can add things
>  like compiler options and firewalls but that doesn't prevent a upstream
>  security hole from being exploited, whether introduced accidentally or not. 
Okay is there any software written specifically for Fedora? KDE gadgets, 
or such?

If so, then I guess we should monitor it at the distribution level.

STF

=======================================================================
http://eisenbits.homelinux.net/~stf/
OpenPGP: 9D25 3D89 75F1 DF1D F434  25D7 E87F A1B9 B80F 8062
=======================================================================

["Stanisław T. Findeisen"]

Todd Zullinger wrote:
>  And, of course, on top of compiler options and firewalls, SELinux is
>  one more layer that is added to protect against problems in upstream
>  code.  If upstream code has some hole that tries to mail off
>  /etc/passwd somewhere, this is very likely to be denied by SELinux.
>  And when someone reports the denial, Dan, Miroslav, and the other
>  SELinux maintainers aren't too likely to allow it without asking what
>  good reason the upstream code would have to take such an action. 
SELinux will not help you more if it gets overwritten/rootkited by 
malicious RPM package (for instance during the install process).

You execute rpm install as root, don't you.

STF

=======================================================================
http://eisenbits.homelinux.net/~stf/
OpenPGP: 9D25 3D89 75F1 DF1D F434  25D7 E87F A1B9 B80F 8062
=======================================================================

[Todd Zullinger]

"Stanisław T. Findeisen" wrote:
>  SELinux will not help you more if it gets overwritten/rootkited by
>  malicious RPM package (for instance during the install process). 
But then we're back to the question of how such a malicious rpm would
get onto your system.  Someone doing such a thing in %post would get
noticed pretty quickly.  If someone packaged up files that overwrote
files provided by the selinux packages, rpm would complain about those
because they would conflict.  So that avenue is a bit tricky.  It's
not entirely impossible, but it's not really easy either.

I don't think this list is the place to engage in endless discussions
on striving for ultimate security (a state that does not exist,
anywhere).

A much better use of time would be in auditing the software that you
can and in finding ways to help improve the process to plug the
limited number of potential entry points for malicious code to be
installed.

(The quote in my sig is entirely random.  Though I sometimes wonder if
fortune isn't just a bit eerie in its choices. :)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A paranoid is someone who knows a little of what's going on.
    -- William S. Burroughs

[Rahul Sundaram]

Stanisław T. Findeisen wrote:

>  Okay is there any software written specifically for Fedora? KDE
> gadgets,
>  or such?
>  
>  If so, then I guess we should monitor it at the distribution level. 
Much of the software originally written for Fedora are used by other
distributions as well like NetworkManager for example. Very very few
components are only in Fedora and developers of the code are responsible
for it's security, same as any upstream software. There is nothing
special about them.  Again, this has nothing to do with RPM.

Rahul

[max]

Stanisław T. Findeisen wrote:
>  Todd Zullinger wrote:
> > And, of course, on top of compiler options and firewalls, SELinux is
> > one more layer that is added to protect against problems in upstream
> > code.  If upstream code has some hole that tries to mail off
> > /etc/passwd somewhere, this is very likely to be denied by SELinux.
> > And when someone reports the denial, Dan, Miroslav, and the other
> > SELinux maintainers aren't too likely to allow it without asking what
> > good reason the upstream code would have to take such an action.
>  
>  SELinux will not help you more if it gets overwritten/rootkited by 
>  malicious RPM package (for instance during the install process).
>  
>  You execute rpm install as root, don't you.
>   
  Selinux might help you there but it depends entirely on the policy in 
use. SELinux has no concept of "root" as you understand it. In SELinux 
root is just another user that can be confined like everyone else, the 
current policy maintains the traditional "root is god" sort of thing but 
this is not a requirement of SELinux but a requirement of its user base.

As to what protection the current policy in use provides against that 
sort of thing, others more qualified may answer in more detail. If 
SELinux interests you then read this :

>  http://docs.fedoraproject.org/selinux-user-guide/ 

-- 
"Any fool can know. The point is to understand" --Albert Einstein

Bored??
http://fiction.wikia.com/wiki/Fuqwit1.0

http://fiction.wikia.com/wiki/Coding_the_Magic_into_the_Eight_Ball

[Bryn M. Reeves]

On Thu, 2009-04-02 at 15:22 +0200, "Stanisław T. Findeisen" wrote:
>  Todd Zullinger wrote:
>  > And, of course, on top of compiler options and firewalls, SELinux is
>  > one more layer that is added to protect against problems in upstream
>  > code.  If upstream code has some hole that tries to mail off
>  > /etc/passwd somewhere, this is very likely to be denied by SELinux.
>  > And when someone reports the denial, Dan, Miroslav, and the other
>  > SELinux maintainers aren't too likely to allow it without asking what
>  > good reason the upstream code would have to take such an action.
>  
>  SELinux will not help you more if it gets overwritten/rootkited by 
>  malicious RPM package (for instance during the install process).
>  
>  You execute rpm install as root, don't you. 
Actually depending on the policy that is configured SELinux could help
here. The root account is not "special" to SELinux and can be confined
just like any other user.

I am not aware of any specific work looking at preventing malicious
packages from harming the system (since most of the work here is aimed
at securing the package delivery and ensuring that packages from
untrusted sources are not installed inadvertently) but there are others
on this list who can probably provide more insight into how well this
could be made work.

Regards,
Bryn.

[Mikkel]

Stanisław T. Findeisen wrote:
>  Todd Zullinger wrote:
> > And, of course, on top of compiler options and firewalls, SELinux is
> > one more layer that is added to protect against problems in upstream
> > code.  If upstream code has some hole that tries to mail off
> > /etc/passwd somewhere, this is very likely to be denied by SELinux.
> > And when someone reports the denial, Dan, Miroslav, and the other
> > SELinux maintainers aren't too likely to allow it without asking what
> > good reason the upstream code would have to take such an action.
>  
>  SELinux will not help you more if it gets overwritten/rootkited by
>  malicious RPM package (for instance during the install process).
>  
>  You execute rpm install as root, don't you.
>  
>  STF
>   
That is why you should only install RPMs with keys you trust.

Then again, if you want to be safe, you should only use code you
have written/inspected yourself, compiled on a compiler that you
have written yourself. After all, it was proven that you could imbed
code in the compiler that would be added to any program that you
compiled with it, and would not show up in the compiler source code.
(The compiler would add the code automatically when compiling itself.)

There is not way to be 100% safe and still have a working system.
You can come close to 100% safe if you never turn your computer on,
and have it locked in a vault someplace. But it would not be very
useful that way.

Now, if you are worried about malicious scripts in RPM packages, you
can always download the packages, and inspect them before installing
them. Even better - only download the source RPMs and build them
yourself. You still run the risk of malicious code in the compiler,
or in RPM itself...

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

[Tim]

On Thu, 2009-04-02 at 10:12 -0500, Mikkel L. Ellertson wrote:
>  if you want to be safe, you should only use code you have
>  written/inspected yourself, compiled on a compiler that you
>  have written yourself. 
And that includes the OS, too.

Real programmers compile on paper, and tap in the hex...  ;-)

-- 
[tim@localhost ~]$ uname -r
2.6.27.19-78.2.30.fc9.i686

Don't send private replies to my address, the mailbox is ignored.  I
read messages from the public lists.

[Mikkel]

Tim wrote:
>  On Thu, 2009-04-02 at 10:12 -0500, Mikkel L. Ellertson wrote:
> > if you want to be safe, you should only use code you have
> > written/inspected yourself, compiled on a compiler that you
> > have written yourself.
>  
>  And that includes the OS, too.
>   
Definitely!

>  Real programmers compile on paper, and tap in the hex...  ;-)
>   
Been there, done that, got the t-shirt. :-)

It is even more fun to toggle in the binary. That way, you do not
have to trust a boot ROM.

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

[Bryn M. Reeves]

On Thu, 2009-04-02 at 10:12 -0500, Mikkel L. Ellertson wrote:
>  Then again, if you want to be safe, you should only use code you
>  have written/inspected yourself, compiled on a compiler that you
>  have written yourself. After all, it was proven that you could imbed
>  code in the compiler that would be added to any program that you
>  compiled with it, and would not show up in the compiler source code.
>  (The compiler would add the code automatically when compiling itself.) 
Here's a link to Ken Thompson's "Reflections on trusting trust" which
discusses these ideas:

http://cm.bell-labs.com/who/ken/trust.html

It's a short essay/talk and well worth the read.

Regards,
Bryn.