Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Mar 2004 17:09:12 +0200
From:      Oliver Eikemeier <eikemeier@fillmore-labs.com>
To:        "Jacques A. Vidrine" <nectar@FreeBSD.org>
Cc:        FreeBSD Security <security@FreeBSD.org>
Subject:   Re: cvs commit: ports/multimedia/xine Makefile
Message-ID:  <40698D98.8010304@fillmore-labs.com>
In-Reply-To: <20040330045649.GE5998@madman.celabo.org>
References:  <200403282344.i2SNi6Hq047722@repoman.freebsd.org> <20040329163309.GA81526@madman.celabo.org> <40686785.7020002@fillmore-labs.com> <20040329185347.GB87233@madman.celabo.org> <40687E18.9060907@fillmore-labs.com> <20040329201926.GA88529@madman.celabo.org> <40689343.4080602@fillmore-labs.com> <20040329224011.GA94303@madman.celabo.org> <4068B425.1070607@fillmore-labs.com> <20040330045649.GE5998@madman.celabo.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Jacques A. Vidrine wrote:

>>>Personally, I was quite pleased with the way that you have it set up:
>>>if users install portaudit, then they will be warned daily about ports
>>>that they have installed; and attempting to build the port results in
>>>much the same thing as FORBIDDEN.
>>>
>>>(I guess I could have some misunderstanding, though.)
>>
>>No, that is precisely the idea: marking a port in portaudit results in
>>much the same thing as FORBIDDEN, so the criteria to add a package to
>>the portaudit database is excatly the same as marking a port as
>>FORBIDDEN because of security reasons.
> 
> That doesn't logically follow.  The criteria for marking a port
> FORBIDDEN is (currently) quite different than the criteria for
> entering an issue into the FreeBSD VuXML document.  I didn't in
> particular create VuXML to replace FORBIDDEN--- although I don't
> object if that is what folks want.

The problem here is that the portaudit database is generated from the
VuXML document, and the criteria to add a package to the portaudit
database *is* the same as marking a port as FORBIDDEN, so I have the
problem of synchronizing the VuXML document and the portaudit database
here.

I can't have a different policy for portaudit, since the results are
the same. Basically portaudit can replace FORBIDDEN, adding a retroactive
view. There is no problem to add an extra flag if a knowledgeable
user wants to have extra security, but this can't be the default.

>>>Without portaudit, we have the current situation.  The only ports
>>>marked FORBIDDEN are those where someone believed that problems are
>>>serious enough to mark it so.
>>
>>This should be the same with portaudit, even on past revisions of the
>>ports: The only port added in the portaudit database should be those
>>where someone believed that problems are serious enough to mark it so.
>>
>>To cite portaudit(1):
>>
>>"If you have a vulnerable package installed, you are advised to update or
>>deinstall it immediately."
> 
> OK, I think I understand your viewpoint.  I believe you are asking for
> some connection to be made between VuXML and FORBIDDEN.  But portaudit
> doesn't *in fact* have anything to do with that policy.  portaudit is
> *in fact* a tool for implementing an alternate policy.

It is not. It hinders you to install vulnerable ports, like FORBIDDEN
does, and notifies you retroactively if a port that should have been
FORBIDDEN is installed. What should be the alternate policy there?

> In other words, you can't equate portaudit's policy with the FreeBSD
> Ports Collection's FORBIDDEN policy.  That's begging the question.

Why can't I? I can't do this for the VuXML policy, but I can for
portaudit. The problem here is that VuXML has a policy that makes
it hard for me to integrate into portaudit.

> [...]
> 
> I specifically do not wish to constrain VuXML entries to only
> those which are ``serious'' (by some widely-accepted definition of
> `serious').
> 
> And I specifically want to avoid assigning severity to entries.  See
> my other recent posting for reasons why.

I guess then I have do do a canditate system, where new vulnerabilities
are only added to the portaudit database when they are verified as
being serious. This means going back to a seperate portaudit database,
which is unfortunate.

I might later implement a notification system for issues with lesser
importance, but I see no point in using portaudit to hinder users to
install a certain port if an issue is not deemed to be severe enough
to mark the port as FORBIDDEN.

>>The decision how severe an issue is has already be made with every commit
>>to the VuXML document (by marking the affected ports as FORBIDDEN or not),
>>it is only not documented. This is just a question of a clearly stated
>>policy, not about assigning a severity - that is already done.
> 
> Well, you do have a point.  So, I'm happy with this approach, but also
> willing to be convinced that other approaches are better. :-)
> 
> Just in case I haven't stated it enough times yet to be clear, I'll do
> it once more:
> If the community wants all ports that become listed in the VuXML
> document to be marked FORBIDDEN--- well, we can arrange that.

It is your document, you can set the policy. If you want to make it usable
for portaudit, give me either a severity tag with a defined policy whether
the port has to be marked as FORBIDDEN or nor, or add only serious entries.

If certain vulnerabilities are not serious enough to hinder people to
install the port, I see no reason for using portaudit to do so.

-Oliver



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40698D98.8010304>