[sf-lug] about /usr/local and package management

Rick Moen rick at linuxmafia.com
Wed Oct 18 14:33:47 PDT 2006


Quoting jim stockford (jim at well.com):
> On Oct 18, 2006, at 9:54 AM, Rick Moen wrote:
> >[1] How to check the security of a system whose software you don't
> >trust is a non-trivial problem.
>
> well, there's downloading the source code, reading every line (and
> understanding each), and compiling and installing.  Seems doable for
> chkrootkit and the like....

...which might suffice if you had any reason to think that the program,
once run, will do what you think it should, even if the machine is
compromised.  Unfortunately, _if_ the machine is compromised, you can't.

See the problem?

> there's md5sum and trusting the maker.

You cannot trust the output of md5sum if it's running on a compromised
system.  The system controls what md5sum sees, what it does, and what it 
outputs.

> there's trusting the distro.

Unwise if the reason you're seeking to run chkrootkit is because you
think your system might be compromised.  (If you mean "trust the
distro's package integrity on its update servers", that's a good start,
but that still leaves not being able to trust the _system_ on which the
tool runs.)

> A NOC guy taught me "trust is efficient". Your tho'ts?

I'm not sure what the guy meant in context -- but I _do_ know that it
seems uncommonly silly to run a security-checking tool on a suspect
(i.e., possibly root-compromised) system and put any faith at all in its
output.

E.g., I have to laugh whenever I hear someone say "Well, I suspected
that my system was root-compromised, but 'rpm -qa' came up clean." 
(If one suspects root compromise, why then are the contents of
/var/lib/rpm/* suddenly trustworthy, not to mention /usr/bin/rpm,
the console support libs, etc.?)





More information about the sf-lug mailing list