3:42 p.m.
"Hewlett-Packard, IBM, RSA Security, InstallShield Software, and Sun
Microsystems are also involved in the File Signature Database (FSDB)
effort. The repository will store metadata about individual files
created by each of the vendors, such as the file's name, a ‘born-on’
date and its digital hash values."
http://www.techworld.com/news/index.cfm?fuseaction=displaynews&NewsID...
Any plans to do that with Red Hat as well?
--
Florin Andrei
"Never send a human to do a machine's job." - Agent Smith
3:49 p.m.
On Mon, 2003-08-11 at 16:42, Florin Andrei wrote:
"Hewlett-Packard, IBM, RSA Security, InstallShield Software, and
Sun
Microsystems are also involved in the File Signature Database (FSDB)
effort. The repository will store metadata about individual files
created by each of the vendors, such as the file's name, a ‘born-on’
date and its digital hash values."
http://www.techworld.com/news/index.cfm?fuseaction=displaynews&NewsID...
Any plans to do that with Red Hat as well?
a neat mechanism to doing this would be:
store the rpm package header from every package released by red hat on
every ver, etc etc.
then you'd be able to go through the header and compare it to what your
ondisk system says to see which files have changed from the original.
it'd be possible to write this in python using the rpmbindings to dump
the file info out of a file from your system, compare it to a remote
header and report back.
it'd be a neat trick too.
-sv
4:02 p.m.
On Mon, Aug 11, 2003 at 01:42:32PM -0700, Florin Andrei <florin(a)sgi.com> said
"Hewlett-Packard, IBM, RSA Security, InstallShield Software, and
Sun
Microsystems are also involved in the File Signature Database (FSDB)
effort. The repository will store metadata about individual files
created by each of the vendors, such as the file's name, a ¡born-on¢
date and its digital hash values."
Any plans to do that with Red Hat as well?
This sounds a lot like what can already be done with a command like rpm -Va.
The rpm database already stores MD5 sums, file sizes, modification
timestamps, file permissions, etc. for every installed package. Packages
themselves can be GPG signed to guarantee authenticity. For added security a
copy of the rpm database along with an rpm executable could be stored on some
read only media and the verify happen from there.
Geoff Reedy
--
Geoffrey Reedy vader21(a)imsa.edu
4:14 p.m.
On Mon, 2003-08-11 at 14:02, Geoff Reedy wrote:
On Mon, Aug 11, 2003 at 01:42:32PM -0700, Florin Andrei
<florin(a)sgi.com> said
> "Hewlett-Packard, IBM, RSA Security, InstallShield Software, and Sun
> Microsystems are also involved in the File Signature Database (FSDB)
> effort. The repository will store metadata about individual files
> created by each of the vendors, such as the file's name, a ¡born-on¢
> date and its digital hash values."
>
> Any plans to do that with Red Hat as well?
This sounds a lot like what can already be done with a command like rpm -Va.
Yes and no.
Yes, it's the same idea.
No, because with FSDB the signatures will be stored somewhere else, on a
trusted site, not on the system itself (not even on the owner's
network). Hence, even if your entire network gets compromised (unlikely,
but still...) you still have a trusted signature database to compare
with.
--
Florin Andrei
"Never send a human to do a machine's job." - Agent Smith
6:07 p.m.
Le lun 11/08/2003 à 23:14, Florin Andrei a écrit :
On Mon, 2003-08-11 at 14:02, Geoff Reedy wrote:
> On Mon, Aug 11, 2003 at 01:42:32PM -0700, Florin Andrei <florin(a)sgi.com> said
> > "Hewlett-Packard, IBM, RSA Security, InstallShield Software, and Sun
> > Microsystems are also involved in the File Signature Database (FSDB)
> > effort. The repository will store metadata about individual files
> > created by each of the vendors, such as the file's name, a ¡born-on¢
> > date and its digital hash values."
> >
> > Any plans to do that with Red Hat as well?
>
> This sounds a lot like what can already be done with a command like rpm -Va.
Yes and no.
Yes, it's the same idea.
No, because with FSDB the signatures will be stored somewhere else, on a
trusted site, not on the system itself (not even on the owner's
network). Hence, even if your entire network gets compromised (unlikely,
but still...) you still have a trusted signature database to compare
with.
Authenticate the package :
# rpm --checksig http://updates.redhat.com/9/en/os/i386/eog-2.2.0-2.i386.rpm
http://updates.redhat.com/9/en/os/i386/eog-2.2.0-2.i386.rpm: (sha1) dsa sha1 md5 gpg OK
Check the installation again the trusted package :
# rpm -V -p http://updates.redhat.com/9/en/os/i386/eog-2.2.0-2.i386.rpm
If the gpg key is not imported or the package have a bad signature :
# rpm --checksig apt-0.5.5cnc6-fr1.i386.rpm
apt-0.5.5cnc6-fr1.i386.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#e42d547b)
--
Féliciano Matias <feliciano.matias(a)free.fr>
11:44 p.m.
On Mon, Aug 11, 2003 at 02:14:11PM -0700, Florin Andrei wrote:
On Mon, 2003-08-11 at 14:02, Geoff Reedy wrote:
> On Mon, Aug 11, 2003 at 01:42:32PM -0700, Florin Andrei <florin(a)sgi.com> said
> This sounds a lot like what can already be done with a command
like rpm -Va.
Yes and no.
Yes, it's the same idea.
No, because with FSDB the signatures will be stored somewhere else, on a
trusted site, not on the system itself (not even on the owner's
network).
There already exists rpmdb-redhat, which you can use (possibly from
readonly media):
rpm -V --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ foo
However a couple of caveats apply:
1) This doesn't seem to be kept in sync with errata, which I can
understand as if you have it installed it's an extra package to update
each time, I guess you could have rpmdb-redhat-errata too.
2) You can't trust it on your system, but no reason you can't have it
from ro media as it's static
3) You don't know you can trust your rpm binary, so I guess a statically
linked one on ro media along with the db would be useful
4) This possibly doesn't help with lkm/rootkits which may be able to do
evil things intercepting your rpm calls. I don't know of any that do
this automagically (quick google), but certainly a bootable cd with rpm,
rpmdb-redhat pluss errata db entries would be simple to maintain.
Paul
11:56 p.m.
There already exists rpmdb-redhat, which you can use (possibly from
readonly media):
rpm -V --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ foo
However a couple of caveats apply:
1) This doesn't seem to be kept in sync with errata, which I can
understand as if you have it installed it's an extra package to update
each time, I guess you could have rpmdb-redhat-errata too.
2) You can't trust it on your system, but no reason you can't have it
from ro media as it's static
3) You don't know you can trust your rpm binary, so I guess a statically
linked one on ro media along with the db would be useful
4) This possibly doesn't help with lkm/rootkits which may be able to do
evil things intercepting your rpm calls. I don't know of any that do
this automagically (quick google), but certainly a bootable cd with rpm,
rpmdb-redhat pluss errata db entries would be simple to maintain.
I think I mentioned this before but it would be a neat idea and it could
help with this problem:
have a db of the rpm headers for a long time back - this would be
dramatically smaller than keeping the actual files - on average an rpm
header is 1% the size of the rpm it is from.
so then you could do the following:
request that a check be done on package foobar on your system
that would - get the epoch,ver,release,arch from your rpmdb for that
package.
look up the header for that package in the remote headers. Download it.
Compare the files on your system to the file/md5sum list in the header
it downloaded. If they don't match return the failures.
If the remote header doesn't exist for the package you requested then
name-epoch-ver-rel-arch then return a failure.
That way the only trust you'd have in your local rpmdb is to tell you
the ver of the package you have installed. And even then it wouldn't be
trusted for the file list.
seriously the functions that would need to be written to perform this
are not hard:
1. md5sum of files on your disk
2. system acl checks of files on your disk
3. matching and downloading hdrs from remote
everything else is interface and glue.
I think this would be a great project to work on if someone had some
time to devote to it.
maybe if I get some time later I'll try to work on it.
-sv
5:27 a.m.
Le mar 12/08/2003 à 06:56, seth vidal a écrit :
That way the only trust you'd have in your local rpmdb is to tell
you
About rpmdb, i have a question that you may find "stupid".
Important : i am not a hacker and my english is poor.
Why yum don't use something like rpmdb for the client part rather than
.hdr files ?
We can gain the power full of the rpm command line tool.
It should be great if yum and redhat-config-packages get on together to
store informations in rpmdb. So we will have all tools (rpm, yum,
redhat-config-packages) that use the same informations.
--
Féliciano Matias <feliciano.matias(a)free.fr>
7:29 a.m.
Le mar 12/08/2003 à 13:47, seth vidal a écrit :
> Why yum don't use something like rpmdb for the client part
rather than
> .hdr files ?
what do you mean? Yum uses the rpmdb and .hdr files for the information
- it just depends on if the package is installed or not.
Sorry. I am talking about rpmdb-redhat witch represent the whole
distribution (/usr/lib/rpmdb/i386-redhat-linux/redhat) and not the rpm
database in /var/lib/rpm that correspond only to packages currently
installed.
$ rpm -i kdegraphics-devel-3.1.2-4.i386.rpm
error: Failed dependencies:
kdegraphics = 7:3.1.2-4 is needed by kdegraphics-devel-3.1.2-4
Suggested resolutions:
kdegraphics-3.1.2-4.i386.rpm <= this come from rpmdb-redhat.
So rpm use /var/lib/rpm and rpmdb-redhat "like" yum use /var/lib/rpm and
and .hdr files.
rpmdb-redhat and .hdr files represent the whole distribution.
-sv
--
Rhl-devel-list mailing list
Rhl-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/rhl-devel-list
--
Féliciano Matias <feliciano.matias(a)free.fr>
10 a.m.
Sorry. I am talking about rpmdb-redhat witch represent the whole
distribution (/usr/lib/rpmdb/i386-redhat-linux/redhat) and not the rpm
database in /var/lib/rpm that correspond only to packages currently
installed.
$ rpm -i kdegraphics-devel-3.1.2-4.i386.rpm
error: Failed dependencies:
kdegraphics = 7:3.1.2-4 is needed by kdegraphics-devel-3.1.2-4
Suggested resolutions:
kdegraphics-3.1.2-4.i386.rpm <= this come from rpmdb-redhat.
So rpm use /var/lib/rpm and rpmdb-redhat "like" yum use /var/lib/rpm and
and .hdr files.
Here are my reasons for not using rpmdb-redhat:
1. rpmdb-redhat only represents the stuff that came originally with the
release, not the updates.
2. rpmdb-redhat is specific to red hat. Yum is not specific to red hat.
In truth I use it on red hat systems but I didn't want to write a tool
that would only work on one distribution.
3. rpmdb-redhat doesn't help with external repositories and that was one
of the goals.
-sv
7563
days inactive
7564
days old
10 comments
5 participants
participants (5)
-
Florin Andrei -
Féliciano Matias -
Geoff Reedy -
Paul Nasrat -
seth vidal