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!
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines