bugtraq - Re: Installation of software, and security. . .

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 19 Jul 2005 15:27:32 +1200
From: Kerry Thompson <bugtraq@...urity.geek.nz>
To: bugtraq@...urityfocus.com
Subject: Re: Installation of software, and security. . .

On Sun, 2005-07-17 at 16:09 -0400, John Richard Moser wrote:
> Exactly my point.  How do you manage or reduce risk when you can't even
> tell what changes are to be made?  An executable has to be run to truly
> understand its actions; scripts can self-modify (variables run as code),
> executables can have odd logic that obfuscates things from heuristics
> examinations.  You can't make an auditing tool to list all changes about
> to be made and actions to be taken by installing the program (aside from
> a spare machine and a debugger).
> 

I agree, you really can't do it that way: auditing any non-trivial
software package is way too hard for anyone ( read: not cost
effective ). But there are systems which can constrain what the
installation process can do and, in turn, what the installed software is
capable of doing on a system.

SELinux, for example, has a security policy for the rpm package
installer. In short, it allows the rpm executable to install new files,
overwrite some files, and set permissions. It permits the execution of
an installation script, but constrains the functions executed by that
script to fairly simple operations like chmod, chown, etc. All other
operations ( eg. network access to download and install the spyware-du-
jour ) is blocked - and blocked at the kernel level.

So while you can't audit package xyz directly, you can ( on the SELinux
system ) constrain what that package is permitted to do. And there are
tools which will audit the policy rules, so you can audit what the
package can do and come up with a worst-case scenario if the package
turned out to be malicious.

There are also other constraints in play in the real world - if a
package distribution site was distributing malicious packages then I'm
sure we would all hear about it, and the repercussions would be swift,
severe, and probably quite a public spectacle.

--
Kerry Thompson
http://www.crypt.gen.nz