FS#11091 - Add package verification capability to pacman
Attached to Project:
Pacman
Opened by none given (hoban) - Friday, 01 August 2008, 20:49 GMT
Last edited by Allan McRae (Allan) - Friday, 14 December 2012, 03:58 GMT
Opened by none given (hoban) - Friday, 01 August 2008, 20:49 GMT
Last edited by Allan McRae (Allan) - Friday, 14 December 2012, 03:58 GMT
|
Details
Description:
Please add the capabilty to verify packages that have been installed by pacman. Coming from Red Hat Linux, I've been very impressed with Arch Linux. One of the few things that I've found missing from pacman is the ability to verify if and how files have changed since they were installed by the package management software. From the rpm(8): "Verify Options The general form of an rpm verify command is rpm {-V|--verify} [select-options] [verify-options] Verifying a package compares information about the installed files in the package with information about the files taken from the package metadata stored in the rpm database. Among other things, verifying compares the size, MD5 sum, permissions, type, owner and group of each file. Any discrepancies are displayed. --snip--" As an example, let's say I hop on an Arch machine that has been fiddled with and my task is to fix it. Let's assume that my LVM volumes were previously being mounted at boot time, and that is no longer the case. As a troubleshooting step, I run "pacman -V initscripts" and I'm given information that looks something like this: S.5....T /etc/rc.sysinit (note that the above output is pulled directly from an rpm -V) From this output, I would know that the Size, md5 sum, and Timestamps of the file /etc/rc.sysinit do not match what has been stored in the pacman database at install time. After further investigation, I realize that I (or someone) had commented out the portion of rc.sysinit responsible for detecting and mounting LVM volumes. This is just one example of the usefulness of this type of functionality. Note that using this sort of verification process as a security mechanism would not be recommended as the database is read-write and could be edited if an intruder happened to get in. <--if this type of functionality is desired, perhaps a package like "tripwire" would be better up to the task. Thanks in advance for your work! |
This task depends upon
Closed by Allan McRae (Allan)
Friday, 14 December 2012, 03:58 GMT
Reason for closing: Fixed
Additional comments about closing: Lots of commits around 01e093d0. Adding checksum checking requires libarchive support.
Friday, 14 December 2012, 03:58 GMT
Reason for closing: Fixed
Additional comments about closing: Lots of commits around 01e093d0. Adding checksum checking requires libarchive support.
Atm I don't think we will implement this soon, sorry (Dan is the pacman leader, so my opinion is not relevant here ;-).
Anyone else have an opinion on this? I'm in favor as long as it doesn't degrade DB performance.
I think having separate scripts with a separate DB could work, but in this case you're probably better off using something like tripwire. I also think it would be very easy for the scripts to become out of sync with pacman.
I realize I've opened a can of worms here, if we really wanted to push for enterprise use, we'd also have to start a security team (if one doesn't already exist...I'm sorry, I'm new to the community) whose responsibility it would be to audit the distro, as well as provide security patches for package rather than just pulling down the latest version from the third-party releaser.
With these things in mind, I'm beginning to think that I ought to be thinking in terms of troubleshooting, as I was when I created the ticket, rather than in terms of enterprise use.
Thanks!
FS#11091andFS#13877dupes?warning: pacman db location is hardcoded in script
if no argument given, it will look for argument on stdin. so it can be used with pipe like
tail -n 20 /var/log/pacman.log|grep upgraded |cut -f 4 -d ' '|python verifypkg.py
@Allan: looking at the checksums from a package in the repo doesn't seem like a good idea. The package could have been updated on the mirrors after you installed it.
And a cache should be just that, a cache. Storing checksums in the database seems wisest to me.
Ps: I could have sworn Xyne did an integrity checker, but I can't find it back. so maybe i'm wrong.
Btw Soltice your script seems like a nice start, though it doesn't work for me as I don't have the package I'm interested in in my cache.
@Dan: it might be interesting to calculate how much the local database would grow to support this feature.
OTOH: since currently the cache is just a cache, I feel safe removing it. If users need to keep the cached packagefiles of all installed packages because at some point they might want to do an integrity check.. that's an overhead which bothers me a lot more.
If we implement this, our local database is going to get significantly bigger and the format will definitely be changing significantly to accommodate more metadata. This would definitely be a nice step but we'd want to make sure we think it through and design it right so this info is easily accessible and possible extensible in the future.
@none: I have no idea where you got the idea we'd be going to the network...
http://mailman.archlinux.org/pipermail/pacman-dev/2010-November/011940.html
* libarchive supports the mtree(5) format, which is an established way of tracking this stuff by the BSDs
* If we are going to make changes to the filelist format in the local DB, I'd love to use an existing format
Then all that needs decided is what to check. I propose:
Directory: uid, gid, mode
File: uid, gid, mode, size, md5, time
Symbolic Link: uid, gid, mode, link, time
See "man mtree" for what those fields are.
I think it would be the weakest link in term of security, but why not ?
It was an idea to stick to KISS with pacman. but the idea of allan don't need a lot of code, I guess, so...
Anyway, I don't quite agree with the statement that this "pacman -V" feature can't be a security measure. Having in mind pacman 4, currently I see two fundamental barriers for this to become a valid security layer (already mentioned in the original report):
1. pacman keyring /etc/pacman/gnupg can be freely tampered with;
2. pacman cache /var/cache/pacman can be tampered with (so there is no way to determine if cache is genuine).
Problem (1) can be solved by deploying archlinux-keyring in a clean environment (e.g. LiveCD) and is outside of pacman's control. However, problem (2) can be dealt with quite easily -- all what's required is storing *.sig files in /var/cache/pacman/pkg alongside with packages. This would add an overhead ~1KiB/package. Is there an option for this already?