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
>checks.
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
>"usr".
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.
--
Dimitri
-------
sig:
"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: