Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Feb 2004 13:41:48 +0100
From:      Oliver Eikemeier <eikemeier@fillmore-labs.com>
To:        Ion-Mihai Tetcu <itetcu@apropo.ro>
Cc:        ports@FreeBSD.org
Subject:   Re: security issues in ports: portaudit and VuXML
Message-ID:  <402CC60C.1000803@fillmore-labs.com>
In-Reply-To: <20040213114956.36b25b44@it.buh.cameradicommercio.ro>
References:  <20040212144522.GB20647@madman.celabo.org> <20040212173817.7315b7d1@it.buh.cameradicommercio.ro> <402C2A1C.4010202@fillmore-labs.com> <20040213114956.36b25b44@it.buh.cameradicommercio.ro>

next in thread | previous in thread | raw e-mail | index | archive | help
Ion-Mihai Tetcu wrote:

> On Fri, 13 Feb 2004 02:36:28 +0100
> Oliver Eikemeier <eikemeier@fillmore-labs.com> wrote:
> 
>>[...]
>>
>>As far as I understand the focus of portaudit and VuXML, they are
>>complementing projects.
>>
>>In the current state portaudit uses a simple flat file database since
>>I needed something to start with and wanted a format that is common to
>>port committers(similar to MOVED), but the system is more or less
>>database format agnostic. Because the distribution file is a simple
>>tar file it is easy to distribute the VuXML database along with the
>>flat file database, or even add signatures.
>>
>>If we decide that the VuXML format is better suited for the job than a
>>flat file database it is easy to integrate it into portaudit in the
>>long run, I have to look into security/vuxml to see what is the best
>>way to synchronize the databases.
> 
> I suggest it's now the time to do that. Both ideas are good, but keeping
> to different databases means updating to different files, which means
> they would get out of sync. See the example on the end.

Thats what the conversion tools should be good for.

>>[...]
>>Currently portaudit is in a development and learning phase, and issues
>>I'm working on are:
>>
>>- a better distribution system, e.g. a script that finds the nearest
>>mirror of the database and fetches the file from there, not from a
>>random location, integrating PR 62655.
>>- a checksum system the checks if a new database is available by just
>>fetching a  md5 sum or a date and not the whole database, like the way
>>clamav does it.
> 
> ;) The idea came when I've exhausted my bandwidth with other traffic and
> a nice three screens cron email came in with "fetch: timeout ..". I'm
> not at all happy with fetch, which fails more often that it should ,
> although  DES's recent commit improves it it a lot.
> 
> I vote for (at least) md5. If someone manages to screw his local
> database this will assure it is corrected on the first run.
> 
> An other idea would be using cvsup against
> security/portaudit/database/auditfile.txt, since the dailly changes are
> not big. So we could have:
> 
> [...]
> 
> The "local" idea: if you cvsup daily you probably have the right
> database in ports. 
> Shouldn't security/portaudit/database/auditfile.txt actualy be
> security/portaudit/database/auditfile.tbz ? Or better yet
> DISTFILES=auditfile.tbz

The idea is nice, but:

- portaudit is designed to work *with* a current ports tree (or a ports tree at all),
  so it may be integrated in the base system

- ports/security/portaudit/database/auditfile.txt is *not* the authorative source,
  it is the file I *currently* use to generate the database, but this may change
  (e.g. merging VuXML in the generated output)

- the .tbz file is generated dynamically and shouldn't be in CVS

>>- a push mechanism that informs systems (by email?) that an updated
>>database is available instead of waiting for the next scheduled check.
> 
> Store somewhere DB_md5 and check once an hour. I don't see how it can be
> done by email (or any other push); I have servers that do not receive
> emails. On the other hand the email should be gpg signed (and this
> complicates the hole thing) as the email To: address will be public so
> anyone could nicely bomb portaudit_updates@my.domain

Using the push mechanism is of course optional, but it is a nice way to trigger
an update on hosts that would otherwise refresh their database every five days.
No real need to PGP sign the mails though, since 1.) it is easy to protect the
list and 2.) the only attack I can think of is a DoS attack against the update
servers.

The push message should only contain a trigger that a new version is available,
not the update itself.

>>- integration of the system into pkg_add of sysutils/pkg_install-devel
> 
> It would be nice, indeed.

Working on that.

> [...]

Thanks for the feedback. net/gaim is an unfortunate example, since we needed some
tries to get it right. I guess I just change the line to <0.75_6 in portaudit since
it is not really beneficial to allow 0.75_4...

Lets see how we can integrate VuXML. Anyone a VuXML -> flat XSLT style sheet?

-Oliver



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?402CC60C.1000803>