LinuxQuestions.org - What are "system binaries"?

- Debian (https://www.linuxquestions.org/questions/debian-26/)

- - What are "system binaries"? (https://www.linuxquestions.org/questions/debian-26/what-are-system-binaries-766935/)

What are "system binaries"?

tripwire - a file integrity checker for UNIX systems, says the best thing is to reinstall the "system binaries" and then start it going. That way it knows for sure the good stuff, I assume.

Err....what are system binaries? I have a vast number of programs on the computer, how do I reinstall them automatically - is there some dpkg, say, (using Debian Lenny 5.0) automatic method?

Quote:

Once an initial database is generated, Tripwire will detect changes
made to files from this point on. You *must* be certain that the
system on which you generate the initial database is clean, however
--- Tripwire cannot detect unauthorized modifications that have
already been made. One way to do this would be to take the machine to
single-user mode, reinstall all system binaries, and run Tripwire in
initialization mode before returning to multi-user operation.

Binaries are all the program files(including libraries) you have installed. What tripwire does is to save every checksum of every program in a database to check later if the file wasn't corrupted.

For example. Imagine that the file /bin/bash has the hash b80dbeb15693587a6de0df349831bddf.
If later the hash of /bin/bash is altered then tripwire will know for sure that the file is compromised(possibly a trojan or something nasty).

Quote:

Originally Posted by ammorais (Post 3745075)

Great thanks. So it remains to reinstall the system binaries.

I know there is some way of making a file that has all the stuff on the computer recorded. Feeding this file to apt or aptitude or dpkg or something will cause it to install all the programs.

How to get the packages reinstalled? Most of them were origionally installed from Debian Official CDs, but it would not be practical to repeat this all in one go - need it to do it down the internet from debian.org, etc..

Gratefull for any help, highly likely I'll cock it up myself.:)

The following should help.

You can get a list of everything installed like this:

Code:

dpkg -l | grep ^ii |awk '{ print $2 }'

Or perhaps

Code:

dpkg --get-selections | awk '{ if ($2 == "install") print $1 }'

You can reinstall a packages with:

Code:

apt-get install --reinstall packagename1 packagename2 packagename3

Putting it together is left as a exercise to the reader :-)

Cheers,

Evo.

PS. You may find it easiest to save the list of packages to a file for possible editing instead of sending it straight to "apt-get install --reinstall"

So I made the list of installed stuff like you said and then had a rush of blood and:

Code:

for i in `cat /home/lugo/listOfInstalled.txt`; do apt-get install --reinstall --yes "$i"; done

Bit of a cock up I'm afraid. First the /var partition filled up. Then it would not reinstall apt-get.

Still works but there are a lot of red messages on closing down.

Cool.

You can actually do it without the loop:

Code:

apt-get install --reinstall `cat /home/lugo/listOfInstalled.txt`

Also instead of passing the --yes you can change the level of importance the questions need to be before apt will ask for an answer.

Code:

dpkg-reconfigure debconf

Then set the level to "critial". It's a little bit safer than just automatically answering yes to everything.

After you are done, make sure that everything is ok by running:

Code:

dpkg --audit

Cheers,

Evo2.

Congratulations! First of all well done for choosing to install a filesystem integrity checker. I think everyone who values their machines should do that. Most people think it's only purpose is security but it may help in terms of management (for instance listing configuration changes) and recovery (being able to compare file hashes) too.

Quote:

Originally Posted by lugoteehalt (Post 3745066)

tripwire - a file integrity checker for UNIX systems, says the best thing is to reinstall the "system binaries" and then start it going.

I hope that's your interpretation of what it reads and not what it actually reads. The gist of the message, a best practice, is to install a filesystem integrity checker right after OS installation but before connecting the machine to any network. This maximizes detecting changes. System binaries are those packages that are vital for operating the OS (think ps, ls, du, init et cetera or rather whole dirs like /lib, /sbin, /bin, /etc and such) as they are the usual targets for subversion by rootkits. I'll go into this all in detail below but anyone reading should realize this is about differentiation. Those that misinterpret this as paranoia may skip the rest and simply dream on.

Installing a filesystem integrity checker long after your OS was exposed to any network is pretty much useless unless you have independent means to verify integrity of package contents (not the MD5 or SHA1 or GPG sig of a package!) by for instance the distributions package manager (if it is capable). This implies that you have stored a backup of the package manager configuration and databases or data dirs off site and are able to verify the integrity of that backup. Debian offers debsums but the obvious problem with that is that it basically is as much an add-on as anything else and not integrated: you can not install it before anything else, you have to (remember to) install it, you have to activate it once manually (if post install scripts don't do that right now). But once you have you can run 'debsums package.deb' using the checksums generated the "package.deb" archive. To top it off, verifying hashes should be done running a rescue or Live CD to avoid tainting results where taints aren't detected.

About choosing a filesystem integrity checker. I don't know whether it's due to hearsay, outdated web logs, outdated articles or lack of coverage elsewhere (I know I pretty much cover this topic at least once a year) but it does surprise me that people still install tripwire while alternatives exist that are not troubled with licensing problems, that are easier to use and that are maintained and supported. But before going into that there's a distinction you may not be aware of: passive versus active.
Applications that need to be started manually or run as cronjob are called passive because they do not run as daemon, continuously. It is important to make this distinction because it means that usage relies on either the person running it or a subsystem driving it: points of failure in terms of forgetting to run it or failing to notice cron daemon or cronjob failures.

In terms of subversion you should also realize the length of any detection cycle is an opportunity for an attacker to modify the configuration and checksum database to enable her to remain undetected. Whichever product you choose it is important to store copies of the binary, configuration, database off site. Also running a filesystem integrity checker may take time. When using a passive filesystem integrity checker you may want to spread risk and load by running different configuration files. For instance you could configure and run Aide on only /lib, /etc, /bin, /sbin once per two hours and use a different configuration to run it on /usr or /usr/local at a different interval.

Examples of passive filesystem integrity checkers are Aide, Integrit, Osiris, Fcheck. (And since the 1.3 series Rootkit Hunter also allows you to checksum system binaries.) The only active one I know of is Samhain. Samhain can run daemonized and offers features like its own LKM to detect kernel changes, encrypted database and (SSL-capable) client-server setup to run with a remote central database-serving host for more resistence against tampering and easier management. Since Samhain runs as daemon it also means it can be run from init, and as you know /sbin/init does not like applications to die and will restart them, meaning one more step towards being tamper-resistant.

* Finally auditing shows one more human point of failure. People may set up the most splendid system but fail to realize that to be able to take (counter)measures one needs to actually read reports...

HTH.

Thanks both.

Oh God:D, it's a technical area. Get this:

Code:

fido:/home/lugo# apt-get remove --purge tripwire

bash: /usr/bin/apt-get: Permission denied

fido:/home/lugo#

So, for security reasons presumably, it is not obvious how to uninstall it.:)

Thanks unSpawn, I do not understand, I've read it once, I'll read it over and try to figure things out.

In the mean time if "system files" are ls, cp, and stuff like that, how should they be reinstalled? Are there a few, sort of binarybox, that's not what it's called, Debian packages?

Quote:

Originally Posted by lugoteehalt (Post 3745932)

I do not understand, I've read it once, I'll read it over and try to figure things out.

Just ask if something is not clear OK?

Quote:

Originally Posted by lugoteehalt (Post 3745932)

In the mean time if "system files" are ls, cp, and stuff like that, how should they be reinstalled?

The question is should they be reinstalled. Has the machine been exposed to the network for long? Has it run any (publicly) accessable services while being exposed? If it has, were there any access restrictions in effect (tcp wrappers, daemon-specific configuration, fail2ban or equivalent, firewall, router)? Regardless of if there were any, would you be able to use 'debsums' to verify specific package (those containing ls, ps and such) integrity against packages from a trusted repo or CV/DVD?

Quote:

Originally Posted by lugoteehalt (Post 3745932)

Thanks both.
In the mean time if "system files" are ls, cp, and stuff like that, how should they be reinstalled?

As described earlier you can reinstall the packages with

Code:

apt-get install --reinstall foo

Finding which package a given command is from can be done in a couple of different ways. For example using apt-file or dlocate (you may need to install them first).

Here is sample of how you could use apt-file.
Fist update the apt-file database

Code:

apt-file update

Then search: eg.

Code:

apt-file search -F /bin/ls

will return

Code:

coreutils: /bin/ls

So ls is in the coreutils package.

NB. You can get the full path to an executable using which:

Code:

which ls

Cheers,

Evo2.

PS. As unSpawn rightly points out, it is questionable if there is really any need to reinstall these packages, but I thought the information about how to do it could be useful nonetheless.