Re: Safer package installation
In message [EMAIL PROTECTED] you wrote: Dima == Dima [EMAIL PROTECTED] writes: 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. Dima Which is even worse, in a sense -- they waste a whole disk Dima block each, using only a few bytes in it. It was my understanding that the ext2fs compacts things so that several small files/symlinks actually are placed in one block. Am I wrong? I didn't know that (obviously :) -- I suppose it would, too. --
Re: Safer package installation
Raymond A. Ingles [EMAIL PROTECTED] writes: Installed packages go to a specific place in the file hierarchy, e.g. /usr/packages/package-name/. There's /usr/packages/name/lib/, /usr/packages/name/bin/, etc. A script then makes symlinks from, say, /usr/lib/file-name to /usr/packages/package-name/lib/file-name. What about performance? I don't think a system full of symlinks would be so fast. -- Alair Pereira do Lago [EMAIL PROTECTED] http://www.ime.usp.br/~alair Computer Science Department -- Universidade de S~ao Paulo -- Brazil
Re: Safer package installation
On Sat, 5 Apr 1997, John Foster wrote: I see a couple of problems: From a users perspective the clourisation option for ls will be close to useless, as almost everything under /usr will be pale blue. Unless you use ls -L. Not to be pedantic (honest!), but from the man page: --- -L If argument is a symbolic link, list the file or direc- tory the link references rather than the link itself. --- Color-ls handles this just the way you'd expect. The other one may be just a problem due to my personal laziness. I like to take some binaries, mv then to old_name.dist, chmod then to 750 and put a little script undr the old name explaining why users can't use binaries they expect to be useable (a slightly fascist approach, but at least I'm polite enough to let them know why!). There isn't any reason why this wouldn't work just the same. Symbolic links reference the file name, so all you need to do is go into /usr/packages/whatever/bin/ and shuffle the files around as you describe above. The symbolic link will point to the script. The old file is right there as /usr/packages/whatever/bin/whateverbin.dist. I assume that the /usr/packages/* would be meant to be modified by dpkg and the install scripts, and not by me (so as to not break too much!). Well, actually, one of the benefits of this scheme is that you can do a fair amount of customization and it's still easy to remove automatically later. You should be able to do quite a bit under the package's root directory without mucking up dpkg. Symlinks inherit the permissions of the source... Well, technically, they inherit the logical product of the source's permissions and the link's permissions. Thus, you can remove permissions with a link, but not add them. Therefore, the permissions the users will see will be *at most* 750. Sincerely, Ray Ingles (810)377-7735 [EMAIL PROTECTED] Modern deductive method: 1) Devise hypothesis. 2) Apply for grant. 3) Perform experiments. 4) Revise hypothesis. 5) Backdate revised hypothesis. 6) Publish.
Re: Safer package installation
On Sun, 6 Apr 1997, Dima wrote: ... Aint that simple -- the standard debian-provided script released yesterday has to know how to handle a new package I will release tomorrow. [...] Well, actually, my description wasn't entirely complete. The idea is, you have a set of directories that specify how links are made. For example: /usr/packages/name/usr/doc- /usr/doc /usr/packages/name/usr/lib- /usr/lib /usr/packages/name/usr/local/lib - /usr/local/lib /usr/packages/name/bin- /usr/bin /usr/packages/name/etc- /etc /usr/packages/name/etc/ppp- /etc/ppp Thus, all the package needs to do is set up the appropriate directory structure in its own area and this is mapped to the wider system in a straightforward fashion. Obviously there are files and directories that shouldn't be mucked with, like /etc/passwd, which Debian *already* prompts for before replacing. This would of course continue. 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. and the only benefits of your scheme is a different (read non-standard) directory structure and heaps of symlinks -- waste of [nowadays cheap] disk space... 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. Almost everyone uses ELF nowadays even though a.out has a very small performance advantage, and I think the benefit/drawback ratio is about the same here. 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. [ add more here ] ... Well, at least one advantage is a *very* quick way to switch between versions of software. If an upgrade doesn't work, it's pretty quick to downgrade if the old /usr/packages/pkgname directory is still around. Also, it can simplify the support of multiple architectures. That's how it's used at work. Also, customization is simpler. If you go to /usr/packages/pkgname, then everything that has to do with that package is right there. You don't have to do as much guessing and searching and such to figure out what files the program needs and where it puts them and so on. And don't tell me I can't exploit the script to screw up people's systems: it has to modify at least /etc, in addition to changing symlinks (unless of course we move all the configuration files from /etc -- nice thing about standards is that we don't have to follow them.) No, the config files still go there, if that's where the software wants them. Aieee, /vmlinuz is a symlink pointing to /usr/kernel-image/vmlinuz, but /usr is not mounted! Not a good day to die! A kernel image is a wonderful example of a package that needs a root-level script to run, to replace /vmlinuz. Some packages *have* to do fundamental system-level operations. That is entirely clear, thank you. What we are proposing is minimizing the number of packages that do that, and mimimizing the number of operations that are performed by the packages that do. Yes, there are exceptions. Indeed. Eg. all packages that have system-wide config files have them in /etc. And we have taken that into account, sorry my description didn't make that clear at first. ... Dselect and dpkg can be set to prompt, This package requires a script to run as user root. Do you want to [e]xamine the script, [r]un it, or [a]bort installation? Read: do you want to suspend dselect, su to root and continue? Do you want to suspend dselect, login as root, install and configure su and then continue? Do you want to do all of the above, go learn Perl, examine the script and _then continue? Oh [EMAIL PROTECTED], why didn't I run dselect as root in the first place? Where's my nearest RedHat mirror? If you don't want extra security, you don't have to have it. 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. ... This does require revision of dpkg, dselect, and the .deb format. And in the end, we will still rely on the very same thing -- that people involved didn't insert malicious code in the package, and that bugs will be soon found by us users, and promptly corrected. 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.) What this offers is
Re: Safer package installation
In message [EMAIL PROTECTED] 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)
Re: Safer package installation
On 7 Apr 1997, Alair Pereira do Lago wrote: Raymond A. Ingles [EMAIL PROTECTED] writes: Installed packages go to a specific place in the file hierarchy, e.g. /usr/packages/package-name/. There's /usr/packages/name/lib/, /usr/packages/name/bin/, etc. A script then makes symlinks from, say, /usr/lib/file-name to /usr/packages/package-name/lib/file-name. What about performance? I don't think a system full of symlinks would be so fast. There would be performance hit, technically, but it should be genuinely negligible. It will only appear as the file is opened, as the system resolves the link. I'm willing to bet that the shift from a.out to ELF would cause more noticeable performance changes. Sincerely, Ray Ingles (810)377-7735 [EMAIL PROTECTED] Modern deductive method: 1) Devise hypothesis. 2) Apply for grant. 3) Perform experiments. 4) Revise hypothesis. 5) Backdate revised hypothesis. 6) Publish.
Re: Safer package installation
Dima == Dima [EMAIL PROTECTED] writes: 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. Dima Which is even worse, in a sense -- they waste a whole disk Dima block each, using only a few bytes in it. It was my understanding that the ext2fs compacts things so that several small files/symlinks actually are placed in one block. Am I wrong? Karl M. Hegbloom [EMAIL PROTECTED] http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU 1.2 Linux 2.0.29t You tell me and we'll both know.
Re: Safer package installation
In message [EMAIL PROTECTED] you wrote: ... If we use the /usr/packages/* method, though, we can separate installation into two steps. The maintainer supplies normal install scripts that handles everything under /usr/packages/package-name/. It runs as, say, user tool, group bin. After that's finished, a separate, *standard*, Debian-provided script runs (as root) that sets up the symlinks, and changes the ownership of /usr/packages/package-name to, e.g., bin:bin. (Or root:root, or package:dialout,dip, or whatever is needed.) Aint that simple -- the standard debian-provided script released yesterday has to know how to handle a new package I will release tomorrow. So we need to wait for the new version of the script, then ppl can install my new package, report bugs, then I release a new version, then we wait for the new version of the script etc. Multiply by slightly more than 1000, which is the current number of debian packages. Ok, the alternative is that the script uses the information provided inside the package, which is precisely what we have now and the only benefits of your scheme is a different (read non-standard) directory structure and heaps of symlinks -- waste of [nowadays cheap] disk space, possibility of symlinks pointing to unmounted filesystems, [ add more here ] ... And don't tell me I can't exploit the script to screw up people's systems: it has to modify at least /etc, in addition to changing symlinks (unless of course we move all the configuration files from /etc -- nice thing about standards is that we don't have to follow them.) Aieee, /vmlinuz is a symlink pointing to /usr/kernel-image/vmlinuz, but /usr is not mounted! Not a good day to die! ... Yes, there are exceptions. Indeed. Eg. all packages that have system-wide config files have them in /etc. ... Dselect and dpkg can be set to prompt, This package requires a script to run as user root. Do you want to [e]xamine the script, [r]un it, or [a]bort installation? Read: do you want to suspend dselect, su to root and continue? Do you want to suspend dselect, login as root, install and configure su and then continue? Do you want to do all of the above, go learn Perl, examine the script and _then continue? Oh [EMAIL PROTECTED], why didn't I run dselect as root in the first place? Where's my nearest RedHat mirror? ... This does require revision of dpkg, dselect, and the .deb format. And in the end, we will still rely on the very same thing -- that people involved didn't insert malicious code in the package, and that bugs will be soon found by us users, and promptly corrected. Your scheme simply removes debian package maintainers from the list of people involved. Since I kinda trust them (have since .93R6), I don't think it's worth the hassle. Regards -- Dimitri reply to emaziuk at curtin.edu.au --- Avoid reality at all costs.
Safer package installation
There's been some discussion on the list lately about the possibility of secure package installation, and whether it's possible, desirable, or practical. Secure installation of Unix software can be complicated, but there are some principles that can simplify things and make it less error-prone and bug-ridden. Scripts to implement safer software installation already exist in the form of opt_depot. Bob Meier and I plan to investigate the notion of integrating this type of procedure into dpkg/dselect. The following is a sketch of our ideas and a call for comments and suggestions. Installed packages go to a specific place in the file hierarchy, e.g. /usr/packages/package-name/. There's /usr/packages/name/lib/, /usr/packages/name/bin/, etc. A script then makes symlinks from, say, /usr/lib/file-name to /usr/packages/package-name/lib/file-name. Deinstallation is a snap. All you do is use find to track down and remove all the symlinks to /usr/packages/package-name/*, and then remove the /usr/packages/package-name/ directory. Note that these two steps have a very high reliability. You will almost never have extra files laying around because the maintainer forgot to update a removal script. Let us reflect for a moment about the contrast between this and Windows. It also enhances security noticeably. The package maintainer can screw up the whole system because of a buggy script the way things currently stand. Imagine the havok caused by the canonical single-typo error rm -r / usr/lib/somedir. I'm pretty sure everyone reading this list has run into problems with buggy install scripts. Bugs happen, and we have to try to minimize the problems any one bug can cause. If we use the /usr/packages/* method, though, we can separate installation into two steps. The maintainer supplies normal install scripts that handles everything under /usr/packages/package-name/. It runs as, say, user tool, group bin. After that's finished, a separate, *standard*, Debian-provided script runs (as root) that sets up the symlinks, and changes the ownership of /usr/packages/package-name to, e.g., bin:bin. (Or root:root, or package:dialout,dip, or whatever is needed.) Thus, a new package cannot affect older, installed packages during installation (they are owned by another user and group, after all). Root's job is simple and well-defined, and pretty hard to subvert. Yes, there are exceptions. Shadow passwords have to muck with /usr/passwd. PPP has to stick a few things in /etc. Mosaic wants to set up three separate directories (one for the software, one for config files, one for documents). Support for installation in more than one directory will be needed. In more complicated cases the maintainer can supply a special script that handles these chores, that will be run as another user, perhaps root. But wait, you say, aren't you giving up your security right there? No, for a couple of reasons. First off, one can determine which packages are most likely to cause system problems simply by asking the question, Which packages need a specially-privileged pre- or post-install script? These can then be singled out for special attention. Dselect and dpkg can be set to prompt, This package requires a script to run as user root. Do you want to [e]xamine the script, [r]un it, or [a]bort installation? Second, the riskier, privileged operations are concentrated in easy-to-find areas by design. A maintainer can't scatter them around multiple places in multiple scripts. They are thus easier to find and therefore easier to monitor and debug. (And probably will receive more attention in the first place when they're written.) This dovetails pretty well with the idea of maintainer certification. You can have looser certification for those packages which don't need special installation handling and rigorous certification for those packages which need root access. (This also helps to make a more standard environment for building source-only packages, BTW. Some have called for more of that sort of thing. :- ) No, this is not a panacea. Bugs will still happen, and security flaws can still be found. But the advantages are clear and, I think, worthwhile. Just knowing that if I uninstall something it won't leave useless files around wasting disk space is wonderful. (How much cruft does the average Windows setup accumulate per year?) Enhanced reliability and security is just a very welcome bonus. (But a *nice* bonus.) This does require revision of dpkg, dselect, and the .deb format. We hope to make the benefits worth the changes. Again, suggestions welcome! Sincerely, Ray Ingles (810) 377-7735 [EMAIL PROTECTED] Is knowledge knowable? If not, how do we know this? -- Woody Allen
Re: Safer package installation
I see a couple of problems: From a users perspective the clourisation option for ls will be close to useless, as almost everything under /usr will be pale blue. I think that ls will have to be modified to set the colour based on the links source - but then how do you identify the symlinks that you want to be blue? Yes, the -F option will still have an @ for symlinks, but is this how ls picks it's colours? I leave this to my betters to consider. The other one may be just a problem due to my personal laziness. I like to take some binaries, mv then to old_name.dist, chmod then to 750 and put a little script undr the old name explaining why users can't use binaries they expect to be useable (a slightly fascist approach, but at least I'm polite enough to let them know why!). I assume that the /usr/packages/* would be meant to be modified by dpkg and the install scripts, and not by me (so as to not break too much!). Symlinks inherit the permissions of the source, so I either have to break the link ihn such a way as to find it again, or modify the permissions in /usr/packages/*, or dpkg has to know a way to deal with this scenario so that my heavy-handed approach is reversible. For example, until the INN thing is fixed, all the newsreaders on my machine are disabled, and a script displays an explanation why to my users. I'll undo this once the /bin/sed thing is fixed. I understand the security/certification issue, but it somehow reminds me of when I used Slackware - You are in a maze of twisty little symlinks, all alike. John Foster.
Re: Safer package installation
Hi, May I remind people that Debian does not depend on any de-install scripts written by package developers, which could have bugs and throw the whole system into chaos (which is just one of the reasons behind the desire to have a secure package installation). So, deinstallation on Debian is already a snap. (Or in any case, no worse than the remove symlinks method would be. May I point out that the simplistic find /remove process is itself a security loophole; but doubtless an actual implementation could try taking care of that.) IMHO, dpkg provides most of the security functionality that the install under /opt and then symlinc into normal areas would. What do we really gain? You are in effect asking us to change the core of what is our package management system; you have to demonstrate your method is actually more secure than dpkg (I admit, the current default of having --force turned on is bad, but the default can be changed). You don't yet have a prima faecie case manoj who has been watching Perry Mason re-runs. -- Never simply say, Sorry, we don't have what you are looking for. Always say, Too bad, I just sold one the other day. -- Robert Skole Manoj Srivastava url:mailto:[EMAIL PROTECTED] Mobile, Alabama USAurl:http://www.datasync.com/%7Esrivasta/
