security issues in ports: portaudit and VuXML

[Ion-Mihai Tetcu]

[ so many lines written and so few good ideas, it seems :) 
 next time I'll try to finish writting when the local time is not about 04 ]

On Fri, 13 Feb 2004 13:41:48 +0100
Oliver Eikemeier <eikemeier at fillmore-labs.com> wrote:

> Ion-Mihai Tetcu wrote:
> 
> > On Fri, 13 Feb 2004 02:36:28 +0100
> > Oliver Eikemeier <eikemeier at 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.

AFAIK synchronizing two databases is not the easiest thing. Doing it
master-slave seems more logical to me; what am I missing ?
 
> >>[...]
> >>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

Ah, logic, OK.
 
> - 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)

That's where the DISTFILES idea came from.
 
> - the .tbz file is generated dynamically and shouldn't be in CVS

(I'm afraid I don't get it here. It should be outside ports/ or src/ but
it would be nice to be able to track somehow the changes, no ?)
I still like the idea of cvsuping this file. If not, maybe the update
should be a diff between versions ? So when the client ask for update he
request the bzip'd diff between his version and -current (like fetch
ftp:/..../diff-1.7-current.tbz). If the things go the right way the
database will increase.
 
> >>- 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 at 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

So it would be something like an opt-in mailing list ? Didn't thought of
that :-/

>  and 2.) the only attack I can think of is a DoS attack against the
>  update servers.

Heh, the las windows update blast must have left some traces in my
brain. ;0
 
> The push message should only contain a trigger that a new version is
> available, not the update itself.

Of course. And some frequency / interval limit should be set,
nevertheless.

> >>- 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...

As it has happened it could happen again, no ? Especially since now only
you and Jacques committed to the two files.

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

I'm afraid is not exactly my area of competence :-( 


-- 
IOnut
Unregistered ;) FreeBSD user