[aklug] Re: DebSig Policies: was: Re: doing a apt-get reinstall everything on debian?

On 01/20/2012 12:05 PM, Christopher Howard wrote:
> Hey Denison, I want to be able to verify packages on my Ubuntu server,
> but haven't got it to work yet. Here is a post that I have made at
> several Linux and Ubuntu forums (and have received no replies):
>
> [START POST]
> Hi. I recently took over management of a small Ubuntu-based e-mail
> server. I tend to be at least somewhat security-conscious, so I wanted
> to figure out how the package verification system works in
> Debian/Ubuntu. (I.e., how I know my packages come from trusted sources
> and have not been modified.) Through a more generic Linux forum I
> learned about debsig-verify. However, when I run it on a deb, I get
> this error:
>
> Code:
>
> debsig: Origin Signature check failed. This deb might not be signed.
>
> I read up in DEBSIG-VERIFY(1) that there are supposed to be policy
> sub-directories in /etc/debsig/policies, along with related keyrings,
> but there are none. How do I install these policies, or where do I
> download them?
> [END POST]
>
> Do you have any information for me?
>

I'd be lying if I said I used debsig-verify, but I should be able to
answer some of your questions. Bear in mind I'm not a security expert;
just a middling systems administrator and jack of all trades. I use
Ubuntu for my own systems (desktop, "server" for remote shell access)
but don't use it in production server environments. Also, there are
people much smarter about this than I, some of them even read this list. :)

Side notes:

* MD5 sums are generally not considered secure.
(http://www.kb.cert.org/vuls/id/836068) There's not a heck of a lot to
do for it till they're replaced with something else - probably SHA256 or
SHA512. But I believe this requires updates to the "deb" file format.

* Trusting the output of commands on a compromised system appears to be
a fool's game. You're probably better off rebuilding from known good
install discs than trying to repair a compromised system.

With that in mind, on to the questions:

> I.e., how I know my packages come from trusted sources
> and have not been modified.

Debian and Ubuntu sign their release lists with gpg - more details are
available here:

 
https://help.ubuntu.com/community/SecureApt#Validation_of_Release_File_and_Packages

   http://wiki.debian.org/SecureApt

As the packages are downloaded during regular updates, they'll be
compared via MD5 checksums against the release lists provided by the
Ubuntu developers.

> How do I install these policies, or where do I download them?

It looks like Ubuntu isn't using debsigs:

   # Do not enable debsig-verify by default; since the distribution is
not using
   # embedded signatures, debsig-verify would reject all packages.
   no-debsig

This is taken from "/etc/dpkg/dpkg.cfg"' on an Ubuntu 10.10 desktop, a
10.10 server is similarly configured by default. There don't appear to
be any packages that might contain keys or pre-built policies either.
At least not in 10.10 and 11.10. If you have the time and inclination,
you could build the infrastructure necessary to do this (say in
conjunction with doing your own local repository for apt); see
http://purplefloyd.wordpress.com/2009/02/05/signing-deb-packages/ for
details more information.

Unfortunately, this doesn't help you verify what's already installed.

"debsums" can help with this. It can verify against the md5 checksums
(usually) provided as part of the deb files, or create md5 checksums for
packages that don't have them. (See the MD5 sum warning above!)

You could also create a list of the installed packages on your mail
server, and then create a mirrored test environment, say in a VM.
Generate a list of checksums from the installed packages on the VM, and
use this list to validate what's installed on the primary system using
(e.g.) the sha256sum command. If you're of the belief the system may
have been compromised, booting from a "known good" cdrom with the
database and running the check would be a reasonable work around.
(Yeah, these are awfully hand-wavy; there's more to it than this. If
you have questions, let me know and I'll try to answer separately, this
mail is getting long enough as-is.)

If you're lucky, the server will have in intrusion detection system
installed - fcheck, AIDE, tripwire, and systraq all do the same thing:
monitor a system for changes in the filesystem and report back
information regarding the changes. I use "fcheck" for my Ubuntu box,
and a bunch of Sun boxes, it's simple and easy to use. If you're more
paranoid it's easy to configure to read it's database off read-only
media (making it harder for Evil Crackers to tamper with it's DB), and
scheduling can be done through cron. AIDE appears interesting, and is
probably my choice for future CentOS boxes. (Mostly because it happens
to be in the repository for CentOS where fcheck isn't.)

Anyway, hope this helps. Feel free to let ask if I left something out
or wasn't clear. I fully expect any errors will be corrected by more
enlightened individuals than I.

R.
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue Jan 24 02:52:27 2012