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

Re: Safer package installation

In message <[🔎] Pine.SUN.3.91.970407120921.22722D-100000@moray> you wrote:
>>Ok, the alternative is that the script uses the information provided
>>inside the package, which is precisely what we have now [...]
> With the exception that the package doesn't muck with the rest of the
>filesystem directly. It has to go through a script with some sanity

Actually you're assuming that package maintainers' scripts have bugs
while the "standard" one doesn't.  IMO what happens is that you introduce
a single point of failure -- the standard script.  ( One can argue both
ways here, you see.  Anyway, that's all a side note.)


> As you state, disk space is now pretty cheap. That's not an excuse to
>wantonly waste disk a la Microsoft, but symlinks aren't exactly huge.

Which is even worse, in a sense -- they waste a whole disk block each,
using only a few bytes in it.


>> possibility of symlinks pointing to unmounted filesystems,
> Now *here* is a substantial objection. This *does* require careful
>attention. The ideal is for /usr to be mountable read-only (as off a
>CD), which is why we assumed we'd put the "packages" directory under

It's not the point.  The point is, there's a 20 MB read-only /, and
the rest is NFS-mounted (for example), and NFS server is down.  Bummer.

I mentioned /etc simpy because it was the one more packages use;
there's also /bin, /sbin, /lib, /dev, /initrd...
Packages that need to modify these should be clearly marked as
requiring more attention than the others -- "required packages
in section base", perhaps? ;-)


> If you don't want extra security, you don't have to have it.

No, I don't want extra security on a single-user box with a dialup
network connection.  I also want my Debian system to fit on 212 MB
hd and run on a 486-66.  (And a pot of gold would be nice, thanks.) ;-)


> Provided that "us users" learn Perl, etc., so we *can* debug them.
>(That same objection applies here too. You can't have it both ways.)

You misunderstood: when a package screws up my system I file a bug
report -- not a patch -- and start crying on the Usenet. I didn't
mean that "us users" fix bugs and generate patches (not that this is
really the case.)

Anyway, that is actually what I meant when I said about trust -- if 
you want to go through the code, you should start with the source for 
the package you're installing.  So it's Perl, awk, sed, shell of various
flavours, C, C++, Elisp, Java...  Machine codes (for eg. Netscape.)
You have to stop somewhere.


> Note that, as Larry Niven pointed out, "There is no cause so noble
>that it will not attract its share of kooks." The BLISS virus is an
>unfortunate case in point. If Debian becomes as popular as we all
>hope, then it will inevitably attract the type of losers who like to
>screw up other people's systems. RootKit is available for Linux, now.

Linux' security is in its openness, as you well know  (I think the
"bliss -uninfect_files_please" (or whatever) got to Usenet before 
McAffee "discovered" bliss.)  
That and bugs in installation scripts are separate issues.


>Dselect/dpkg can be configured to avoid prompting if it's already
>root, or a command-line option can be set up. This is not a reason to
>ditch the idea of providing extra security to those that want it. Even
>if dpkg is running as root, it can still run the non-privileged
>scripts as a less-empowered user to minimize the damage that bugs in
>those scripts can cause.

I agree, in theory.  I just can't see that your method of doing that
is feasible -- you've got to change the whole package management system,
substantially change filesystem layout, change programs (like ls, file
and others that will undoubtedly pop up); note that the last two are
covered by standards -- FHS (?) and POSIX resp.

As I pointed out, all these changes minimize the damage caused by bugs
in installation scripts; they don't help with bugs in the packaged 
applications, viruses in packaged binaries and so on.  You're proposing
to invest a lot of time and effort into a rather minor stage in package
development process.

Of course, all of the above is IMO only.  Also, IMO, we could try to
implement a capability-type system where dpkg matches install-script's
key against locks on each file the script tries to modify (stored in
/var/lib/dpkg/info/<package>.list, possibly, or Contents.gz.)  This 
would be quite inefficient, of course, but then lock-key capability 
systems usually are.

 "By US Code Title 47, Sec.227(a)(2)(B), a computer/modem/printer meet the
  definition of a telephone fax machine.  By Sec.227(b)(1)(C), it is unlawful
  to send any unsolicited advertisement to such equipment. By Sec.227(b)(3)(C),
  a violation of the aforementioned Section is punishable by action to recover
  actual monetary loss, or $500, whichever is greater, for each violation."
(Solicited advertisements <huh?> and other such can be sent to 
  emaziuk at curtin.edu.au)

Reply to: