Crack? Cops?
I noticed in my slink snapshot (from last month) that 'cracklib2' exists, 'crack-dict' is suggested but *doesn't* exist (either as a package or in the 'Packages' list), and 'crack' is nowhere to be seen. Is the omission of 'crack' deliberate, or does it need a maintainer? US export policy should be no more of a problem than it is with /bin/passwd and /bin/login. On a related note, I noticed that 'cops' is absent. Again, is this deliberate or does it need a maintainer? Neither package is listed on the prospective packages. Bear Giles [EMAIL PROTECTED]
kerberos, encrypted file systems, secure-linux 0.6, more
I'm wrapping up my first beta disk for (*sigh*) US-only GNU/Linux security tools. As many of you know, this quasi-distribution was the cause of some recent discussions. See [1]. This quasi-distribution contains material which definitely *cannot* be exported without permission from my dear uncle: - an initial MIT Kerberos 5 package. Kerberos 4 is available from non-US, but the foreign K5 package is apparently not ready for regular use. - several packages recompiled to use Kerberos 5/GSSAPI authentication: CVS, LPRNG, IMAP. Packages which use Kerberos 4 authentication (e.g., AMANDA) have not been recompiled since they can be distributed in non-US. Actually, these packages are already exported. But nobody outside of the US/Canada can rebuild them. :-( - Kernels 2.0.35 and 2.0.36 rebuilt with support for the Berkeley (cypherpunks) encrypted file system. The loop device changed significantly in 2.2.0, so I don't know when support will be available in that line. (uname: 2.0.x-efs). See the article in Linux Journal about a year ago. (This also requires a patched 'mount' from util-linux 2.9g, and that in turn might require newer packages.) (These patches may also be available outside of the US; if so, someone else could package these kernels for nonus.) - xfree86 rebuilt with support for XDM-AUTHENTICATION-1. Unlike MIT-COOKIES-1, this authentication method is secure even when a network sniffer is present. The xfree86 MIT-KERBEROS-5 code expects a different API than the MIT k5-1.0.5 distribution, so I don't have support for it yet. (This is 3.3.3.1 with modified makefiles from a December slink snapshot.) - non-US mirrors for hamm and slink, since I'm not repackaging files already available from those sites. Before you dismiss the entire idea of US-only packages, I need to point out that several large companies are already folding Kerberos authentication into their tools. Windows NT 5 may not be out for years, but some cable modem systems use Kerberos authentication (or a derivative of it) today... and these same cable modem system use the lack of Kerberos support in Linux as a reason for not supporting it. (The Kerberos support in Windows 9x may only be a crippled DLL... but it's on the free software disk these companies hand out.) Likewise, some universities use Kerberos authentication for their on-campus networks. In other words, is this glass half full or half empty? This disk also contains some material which should be exportable, and I'm offering them for incorporation into Debian (modulo the comment below): - kernels 2.0.35 and 2.0.36 patched with secure linux 0.6. (http://www.false.com/security/linux/). I don't have too much doubt about the value of the patches (do a yahoo search on +secure-linux +patch, but in light of moduleinfect.c and the problems with TCP-wrappers and util-linux I'm paranoid that the patches might have been corrupted. Some documentation follows. (uname: 2.0.x-s). - rainbow: the rainbow books on computer security, from http://www.radium.ncsc.mil/tpep/library/rainbow/. I don't recall seeing an explicit copyright statement, but government documents on a government site should be public domain. (I can always file a FOIA :-) I would simply upload these packages, except my new maintainer status has become controversial and I don't have access to the upload area. I'm also looking for a distribution site which can handle a large amount of data subject to US export control; that eliminates cheap host sites and all OSS sites with automatic mirrors. A limited number of CD-R disks are available for beta testing. Preference will be given to sites running Kerberos (typically, large universities and some cable modem systems). I'll also send one to anyone (modulo below) for the price of materials and postage; call it $5.00. Due to export regulations, I can only ship the disks to US and Canadian residents. I also need your e-mail to state that you do not intend to export it in violation of US or Canadian law. I agree the law is stupid and grossly misguided, but I'm still working to change the system from within. Bear Giles [EMAIL PROTECTED] - [1] For the record, I highly value fairness. In the past, some of my employers have tried to claim that *any* code I work on at *any* time and under *any* circumstances is their property. I told them to take a flying leap. I've had universities tell me that all code developed for classes was their property... and as a graduate student we weren't always talking about trivial programs. I said no way, gave them a theoretical question involving research motivated by a real world problem faced by my employer, then did all of my work on my own hardware. I firmly believe the same thing applies with volunteer efforts. When I'm volunteering work for Debian, it can set reasonable
Re: Proposal: increasing mirror security
Jason wrote: I would prefer to use the idea of a trusted site (like ftp.debian.org) to fetch package file MD5 summs from, that way we do not get involed with the sticky issue of cyrpto hooks. What about: 1. Every package already contains MD5 checksum. 2. Each section contains two new files. The first is a list of (package name, checksum, signer, signed checksum). The signer would be the packager, who presumably already has PGP/GPG. The packager, in turn, would normally be the package maintainer. But this isn't necessarily always true, to the system needs to be flexible enough to handle a more general case. The second file is list of (signers, public keys). With offical packages, this list is already published in a package -- something which must be considered dirty until we find some other way to verify it. However we *could* sign this list by a trusted public key which is available from a canonical site, e.g., ftp.debian.org. This key should rarely change, so people will rarely need to ping the site. Authentication is then fairly simple: 1. Verify we have the current top-level public key, or download it. 2. Verify the signature on the list of signers with #1. 3. Verify the MD5 checksum signatures for each package with #2. 4. For each package, verify that the three MD5 checksums match. (Signed checksum, package checksum, and computed checksum). This system has several benefits: 1. It eliminates the chokepoint of checking ftp.debian.org for all signatures and/or checksums. It's entirely self-validating once you have that particular trusted key. 2. It only requires signatures by two parties. Packagers, who are presumably entering their pass phrases already, and the list of signers. That list would only change as maintainers are added or change their keys. 3. If you allow multiple top-level signers, it can support packages which use .deb format but aren't offical debian packages. E.g., I've created debian packages at work to manage internal tools used by my employer. These companies were small enough that everyone who used these packages knew me and could easily verify the package, but that's not true in many packages. and it requires that the clients know exactly which key to expect so changing keys becomes difficult. More precisely, they need to know who did the signature. Propogation of changed keys is a separate problem which must be addressed in any protocol. We are not very vunerable to the sort of attacks we have heard of, someone could go onto a mirror and could change a file and change the Packages file but they would have to do that every single day! But how many people will download the packages in the meanwhile? Bear Giles [EMAIL PROTECTED]
Re: Crypto software that *is* exportable from the USA
Bear Giles [EMAIL PROTECTED] wrote: But you're biting your own tail here. Where do you get that good checksum? Any place which is acceptable to the package maintainer -- perhaps out of a pgp signed archive. Remember, the start of this discussion was an (FTP) mirroring program that got around encryption export laws by importing software from a site in South Africa. The problem isn't in *producing* a package, it's in *acquiring* that package later. What happens if someone successfully attacks a site immediately before you mirror it? MD5 checksums aren't adequate, since the attacker can forge new ones. Cryptographically signed checksums don't help, since the software (at time of export) can't include the software to verify them. Downloading PGP from the ZA site won't help because you can't verify *its* checksum. Even if you hardcode in the signature for a known good copy of PGP, download and verify it, then use it to download and verify the latest version, *how do you know your original package was valid*?! Maybe the copy you downloaded actually downloads from blackhat.com.za. Bootstrapping is hard -- best you can do for the general case is compare notes after you've gotten a secure system up. And that, it seems, is exactly the problem that this program seeks to fix. Bear Giles [EMAIL PROTECTED]
Re: Crypto software that *is* exportable from the USA
Wichert wrote: Previously Paul Sheer wrote: Also: there is no GPL secure shell (as far as I know). But people are working on that. From what I hear it's on the verge of becoming useable. Don't ask me about the name, I always forget it. MIT Kerberos (4 and 5) is open source and provides strong authentication (and optional encryption) of telnet, ftp, rsh, rcp, and more. Kerberos 5 is currently US-only, but Kerberos4kth is a foreign implementation that is available at nonus.debian.org. I believe this site also has an SSLtelnet program, built using SSLeay. Bear Giles [EMAIL PROTECTED]
Re: Crypto software that *is* exportable from the USA
It supports strong encryption but is exportable from the US because it does not have encryption compiled in by default. Instead it downloads the scripts it needs from South Africa when it runs for the first time. This is *extremely* risky behavior. FTP and HTTP sites *are* compromised. Software packages *are* compromised. Look no further than TCP Wrappers... A major part of the security process is having a human involved who knows what software was downloaded. A human may later see a pertinent news report and act on it; scripts will not. A *mandatory* part of a site's security process is having a human who has the final authority to approve the use of a package. A human who can be held accountable, and thus is motivated to pay attention to what's going on. A script blows off this part of the process. South Africa has no export restrictions on cryptography. It supports file transfer and secure logins shells. It can offer secure file transfers and multiple cryptographic checksums, and the end result is just as unacceptable. *We must start with the assumption that the server might be compromised.* If the server is compromised, secure login shells and FTP won't help. If the server is compromised, checksums (even MD5 checksums) won't help. The only thing resilient to compromised servers are cryptographically signed cryptographic checksums. Which requires PGP. Which is not exportable. And which requires a chain of trust to evaluate whether to trust the key used to sign the checksum. What's the answer? Download *PGP* to verify the checksums on that PGP file,... ? As an aside, why would a mirror program even want strong encryption? Encryption != authentication, although the implementatons have significant overlap. Bear Giles [EMAIL PROTECTED]
Re: Crypto software that *is* exportable from the USA
Bear Giles [EMAIL PROTECTED] wrote: The only thing resilient to compromised servers are cryptographically signed cryptographic checksums. Which requires PGP. Which is not exportable. And which requires a chain of trust to evaluate whether to trust the key used to sign the checksum. Actually... for the case of a pre-planned upgrade, a simple md5sum check -- that the downloaded file has a md5sum which matches an archive which has already been examined and seems clean -- would be sufficient (at least in terms of mechanical integrity). But you're biting your own tail here. Where do you get that good checksum? You can't get it from the archive site, since a compromised archive implies that the local MD5 checksum may also be compromised. If the attacker doesn't replace the checksums, great. If he does If you distribute it as part of your package, you can't load newer packages... which makes the entire exercise academic. If you distribute it from a trusted site, then compromising *that* site results in the same problem. Even if you try to bootstrap the system, how do I know that the package I get was the one you wrote? How do I know that the TLD tables haven't been corrupted, or a DNS entry hijacked, or And again, what is the problem you're trying to solve that requires strong encryption in the mirroring software? AFAIK, MD5 checksums are *not* export restricted. Bear Giles [EMAIL PROTECTED]
Re: Debian Re-organization proposals (was: Re: so what?)
On Wed, Jun 03, 1998 at 11:17:15AM +0100, Philip Hands wrote: Democracy would give the majority the feeling that they have the right to tell the few what to do, which they absolutely do not have. That is the major falling of every democracy[...] There are many different types of democracies. Universal franchise democracies are *very* dangerous, for reasons well known (and easily seen) by anyone interested in the matter. On the other hand, proportional (or corporate) democracies can be remarkably stable. In the case of Debian, a pretty straightforward democracy can be implemented by voting by shares, where one share == one package. You could also weigh shares by category; e.g., an essential package is worth 5 shares, an optional package is worth 2 shares and an extra package is only worth one. That keeps control in the hands of the people who do the work, and they're the ones most likely to know what needs to be done and the true cost of trivial changes. Also, since the voting majority rests in the hands of relatively few individuals, they can generally lead by consensus amongst themselves. If someone disagrees with their policies, they can easily gain a louder voice by carrying a greater share of the load. Since I haven't had time to work on the Hesiod package for several weeks (not even to recompile it with libc6), I have zero shares and you're certainly free to ignore me! :-) Bear Giles [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Initial partitions
[1] I don't why my system always reboots in read-only mode now; Umm, what kernel were you running before? Debian 1.3, from a Walnut Creek CD-ROM dated late last year. It was one of those 6-CD set! deals; I bought the bundle so I could install the best on my personal systems, yet still install the politically acceptable at work! :-) N.B., the system *did* boot after I ran autoup.sh, and it rebooted after I loaded a number of packages from hamm. (no more than 25 packages). It didn't reboot after I downloaded and installed a big chunk of hamm. (My hamm directory is about 160 MB now, most of it downloaded yesterday and most of it installed before I called it a night.) Further complicating the issue I loaded a minimal 1.3 into my CD-R scratch space (/dev/sda4). I then upgraded to libc6, and installed lilo-20. I could boot direct to /dev/sda4, but not /dev/sda1. When I boot from /dev/sda4 I *can* modify the contents of /dev/sda1. This is true when running either libc5 or libc6. I would show you the log messages, but (duh) the disk is read-only and the log messages aren't written. I know that there are a lot of secondary failures since I can't mount /proc (which modifies /etc/mtab)? I can't install modules, apparently for the same reason. I can't run various services, since they write information to /var/run. I can't write syslog messages to /dev/tty12, since I can't change ownership. The system doesn't even know its own name, so my login prompt is (none) Login:. Hmm; I think I'll try a few more tricks to grab the log messages... Bear Giles [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Initial partitions
I upgraded to libc6 and hamm this weekend... and had my entire root partition flagged readonly by an unknown mechanism. This got me cursing and thinking[1] Ideally the issue should never come up, but hard disks fail. Hard disks are replaced as hardware is upgraded. Occasionally things get totally hosed when you push the edge. The information maintained in dpkg (theoretically) specifies the contents of the file system except for /etc, /var, /usr/local, and /home. Furthermore, many (even most?) people won't do anything too fancy with /etc, /var or /usr/local, especially if any servers (e.g., web and ftp) use /home instead of /var for their data files. This suggests that it may make sense to recommend that the default disk configuration is three partitions, not two: / (existing) /home (new) (swap) (existing) since even if the system must be reinstalled from original media, the user won't lose their personal files (although they may lose some mail). Taking this a step further, a fixed-size /var partition could be specified with the expectation that it will maintain status logs even after a reinstallation. Setting up two ext2fs partitions instead of one is a bit of a pain... but nothing compared to the hassles if the disk is set up as one big partition when something goes wrong. Should the installation script be modified to suggest multiple partitions? Bear Giles [EMAIL PROTECTED] [1] I don't why my system always reboots in read-only mode now; since I can't log in I have little information. It's not a problem with the partition table, lilo configuration, or /etc/fstab. Also, I can boot off a different partition on the same disk (although it is still 1.3). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Mnemonic? (possible intent to package...)
Would it be worthwhile to package mnemonic, even though it's still in an early alpha state? Mnemonic (http://www.mnemonic.org) is a multithreading modular web browser built heavily on GIMP. The modular design allows you (AFAIK) to determine the tradeoff between your local footprint vs. capabilities. (E.g., do you want a simple, but fast, text-only browser akin to Lynx, or something that can handle *anything* like Netscape?) Finally, it's GPL. But, as I mentioned, it's also still early Alpha -- as in a *single* public release to date. Is that too early for packaging? If not, does anyone know where dlfcn.h (as I recall) comes from? It's used in the mnemonic objectmanager.cc file, and a query to the email address hasn't produced a result. I searched the (likely) source tarballs at the site and couldn't find the file in any of them. Bear Giles [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: monochrome cards
Jason Gunthorpe [EMAIL PROTECTED] wrote: On Thu, 30 Apr 1998 [EMAIL PROTECTED] wrote: 2. Make sure that the color monitors are supported automatically from the installation screen itself. Thats a good point, who actually has a truely MONO screen anymore? [...] I think machines with a mono video card (ie a herc) would be unable to run Debian in the first place, and a greyscale screen doesn't need mono support. I decommissioned my 386DX-40 with a Hercules knockoff less than a month ago; it was running the same version of Caldera as my primary system. I have no doubt that this system would run Debian... and run it very well. (Esp. considering I just installed a complete Debian package, including X-windows, on a 486-_33_ at work!) That said, I can't see anyone using a MCA card as his primary interface. I certainly wouldn't have objected if I had to install a VGA card to run the installation program. How much space would be saved if the MCA code is dropped? Hmm... maybe I should install X-mono on that 386. Not that I expect it to be particularly useful, but it's an *extremely* impressive demonstration for people who don't realize just how little compute power is required to support browsers, basic editors, etc. Bear Giles [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: monochrome cards
From: Jason Gunthorpe [EMAIL PROTECTED] wrote: Actually, you'd be insane to put a MCA card in a server (you'd have to get it second hand and so on). They generally slow down the machine because of the limits they place on the ISA bus and require special mca screens! When you're only running at 30-40 MHz anyway, how much could the video card slow down the ISA bus?... :-) Also, the MCA monitors aren't special, just incompatible with the (now) much more common CGA and VGA cards. I wonder if you can probe the kernel to find out if it is using a MCA card, it actually does know (diff memory address).. If someone wants to try out some software on my system, let me know. I can easily upgrade its kernel to 2.0.33. Bear Giles [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mnemonic? (possible intent to package...)
On Thu, 30 Apr 1998 17:22:12 MDT Bear Giles ([EMAIL PROTECTED]) wrote: If not, does anyone know where dlfcn.h (as I recall) comes from? % dpkg -S dlfcn.h libc6-dev: /usr/include/dlfcn.h I also found it in libc4-dev, but not libc5-dev (5.4.33-3). Is this a bug? P.S., I thought that GTK was GIMP Tool Kit and that ultimately the GIMP package would be split into two packages, the GTK and the GIMP clients. Other packages could require GTK without loading the rest of GIMP. Bear Giles [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License advice
On Mon, Apr 27, 1998 at 11:36:00AM +0200, Kai Henningsen wrote: However, it is not as obvious as you want to make us believe. Things that are not explicitely allowed are forbidden. Things that are not spelled out, are not there at all. There is only little room for interpretation of legal texts. You're assuming that this rule applies everywhere and in every situation. In the US the assumption often goes the other way; anything not explicitly forbidden is permitted (up to the limits of lawful action, of course :-). There's even an extra-legal phrase to describe this attitude: it's better to beg forgiveness than ask permission. Needless to say, the license should be unambiguous since two reasonable interpretations exist. Since we don't have that, where does the author live? What is the legal convention there? Is it everything not allowed is forbidden or everything not forbidden is allowed? Bear Giles [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
