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

Re: ssl security desaster



Tollef Fog Heen <tfheen@err.no> writes:
> * Martin Uecker 

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

I've thought for a while that the best solution to this would be to write
an interpreter with a *very simple* language that understands the
semantics of Debian maintainer scripts and understands how to do the 50 or
100 most common things that people have to do in maintainer scripts.

I think that writing a mini-language with very simple semantics, designed
to be very easy to parse and analyze with automated tools, that supports
80% of what people do in maintainer scripts would be fairly
straightforward (easily within a Google Summer of Code project).  Packages
could then have the option.  Packagers could depend on that interpreter
and use the mini-language, or they could fall back to shell or Perl the
way that they do now for the complex cases.

You'd probably want to skip config, preinst, and postrm support for the
first pass until it's proven to be a good idea and one has built
justification for making the package essential, but the long-term goal
would be to have that interpreter become essential and have it be the
default way of handling maintainer scripts.

You can then still bail on packages that do things that are just way too
hard and maintain that escape to stronger languages, while still gaining
all the benefits of a highly restricted and simple language for the vast
majority of packages.

I of course have absolutely no time to work on this.  :)  But it's not
something that anyone would need permission or approval to start doing.
Anyone could do this right now, propose the language design for peer
review here on debian-devel, and upload a package that implements it, and
people who want to start experimenting with it could have their packages
depend on it.  (debhelper support would of course be useful at a fairly
early stage, since a fairly substantial percentage of our maintainer
scripts are generated at least in part by debhelper.)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: