[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ssl security desaster

Tollef Fog Heen wrote:
> * Martin Uecker 
> | Another problem I have argued about before, not directly related to this
> | incident, but IMHO another desaster waiting to happen: There is no
> | way to independetly validate that a debian binary package was
> | created from the corresponding source.
> How would you go about doing that?  If you just mean «all packages
> should be built on the buildds», that's fairly easy to do, but if you
> are talking about actual verification of source => binary which can be
> done post-mortem, that's much harder.

Actually, it's not that hard. If you build a package in a controlled
environment, you get something which is in most cases already very
reproducable. For many packages there are only a few time stamps
which somehow end up in the built that make it non-reproducable.
Since these time stamps are not really usefull anyway they could
simply be removed. There was a thread "building packages with exact
binary matches" about it. Unfortunately, most people seem to think
that this is not worth it.

> | What bothers me too is the fact that the installer scripts of all
> | packages have root permissions during installation. While this might
> | be hard to do, in principle I see no good reason why installer
> | scripts could not be limited to certain tasks.
> I believe that postinsts need the flexibility shell (or perl or python
> or whatever) gives them.  If you want to restrict postinsts to only be
> able to do a limited set of operations, the quality of packages will
> detoriate quite a bit as they are no longer flexible enough to cater
> for all packages's needs.

A lot of packages have very simple scripts often only updating some
kind of index after installation which could be done with triggers.
In these cases, the scripts could possibly removed completely.
Checking that the package does not overwrite files from other 
packages and installs files only to certain directories would then
limit the security risks from installing the package to the users
of a system which actually do use the software.

In other cases, it might be possible to lock the scripts down with
selinux, as Manoj pointed out in the thread mentioned above.


Attachment: signature.asc
Description: Digital signature

Reply to: