* Linux crypto? @ 2002-05-22 18:03 Myrddin Ambrosius 2002-05-22 18:38 ` Alan Cox 0 siblings, 1 reply; 31+ messages in thread From: Myrddin Ambrosius @ 2002-05-22 18:03 UTC (permalink / raw) To: linux-kernel I noticed that Motorola has published a set of tech docs for their S1-range of crypto co-processors, which look pretty comprehensive. (The 190 looks to be a very nice chip, which -as best as I can tell- just plugs straight onto a PCI bus.) Other co-pro manufacturers (such as HIFN) seem to also have humungous tech manuals for their crypto chips. Is anyone working on drivers for these beasties? Alongside that, I also noticed that many manufacturers (again, Motorola and HIFN seem to top the list) working on network accelerator chips - some h/w L2/L3/L4 queueing/filtering, rudimentary packet mangling, etc. Linux already has most of the interesting stuff from the chips I've looked at, and in most places is way more advanced in what it can do/ Given the ipfilter design, would there be any way to use those chips as an additional networking layer? (And, just as importantly, would there be any point?) Secondly, I've taken a look at the "International Kernel Patch" for Linux. I have finally found a (fairly) mainstream kernel patch that is updated less frequently than my own FOLK patch! Also, nobody seems to use it. Packages that use crypto seem to steer towards openssl, rsa-ref, mcrypt/mhash/gcrypt, gnutls, and/or or private implementations. Even FreeS/WAN and USAGI take no advantage of anything in the IKP. Ignoring, for a second, the US export laws (which are no longer an issue, anyway), is there some fundamental reason why the IKP seems to be ignored? If there is, then does anyone know of any re-design/re-write effort? __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-22 18:03 Linux crypto? Myrddin Ambrosius @ 2002-05-22 18:38 ` Alan Cox 2002-05-23 8:45 ` Trond Myklebust 2002-05-23 21:46 ` Tobias Ringstrom 0 siblings, 2 replies; 31+ messages in thread From: Alan Cox @ 2002-05-22 18:38 UTC (permalink / raw) To: Myrddin Ambrosius; +Cc: linux-kernel > I noticed that Motorola has published a set of tech > docs for their S1-range of crypto co-processors, which > look pretty comprehensive. (The 190 looks to be a very > nice chip, which -as best as I can tell- just plugs > straight onto a PCI bus.) Other co-pro manufacturers > (such as HIFN) seem to also have humungous tech > manuals for their crypto chips. > > Is anyone working on drivers for these beasties? You might want to check on the apache and openssl lists. A lot of crypto drivers are handled from userspace directly or with modules that don't hit the base kernel. > Given the ipfilter design, would there be any way to > use those chips as an additional networking layer? > (And, just as importantly, would there be any point?) Some of that probably can be offloaded. You'd need code (preferably in the user tools) that can compute if a given path through the ipchains rules is expressable in the hardware and if so to enable it. In terms of things like flow control and other magic try netdev@oss.sgi.com. Dave and Jamal get very excited when they talk about NAPI but it just makes my head hurt 8) > Ignoring, for a second, the US export laws (which are > no longer an issue, anyway), is there some fundamental > reason why the IKP seems to be ignored? If there is, > then does anyone know of any re-design/re-write > effort? What of it do you actually need in kernel space - encrypted file systems certainly ought to be there but are not very well handled in Linux proper right now - but anything else ? ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-22 18:38 ` Alan Cox @ 2002-05-23 8:45 ` Trond Myklebust 2002-05-23 21:46 ` Tobias Ringstrom 1 sibling, 0 replies; 31+ messages in thread From: Trond Myklebust @ 2002-05-23 8:45 UTC (permalink / raw) To: Alan Cox; +Cc: Myrddin Ambrosius, William A.(Andy) Adamson, linux-kernel >>>>> " " == Alan Cox <alan@lxorguk.ukuu.org.uk> writes: > What of it do you actually need in kernel space - encrypted > file systems certainly ought to be there but are not very well > handled in Linux proper right now - but anything else ? Authentication... At the Connectathon in February, we got as far as setting up a working test machine for the RPCSEC_GSS kerberos V5 authentication on the NFS and RPC clients. AFAIK, Andy is currently working on adding support for SPKM auth. and data encryption. I'm not sure exactly which ciphers we need for all this (Andy can perhaps comment?) but we'd definitely want to see part of the crypto patches go into the standard kernel at some point soon. Cheers, Trond ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-22 18:38 ` Alan Cox 2002-05-23 8:45 ` Trond Myklebust @ 2002-05-23 21:46 ` Tobias Ringstrom 2002-05-24 14:58 ` Alan Cox 1 sibling, 1 reply; 31+ messages in thread From: Tobias Ringstrom @ 2002-05-23 21:46 UTC (permalink / raw) To: Alan Cox; +Cc: Myrddin Ambrosius, linux-kernel On Wed, 22 May 2002, Alan Cox wrote: > What of it do you actually need in kernel space - encrypted file systems > certainly ought to be there but are not very well handled in Linux proper > right now - but anything else ? IPsec. /Tobias ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-23 21:46 ` Tobias Ringstrom @ 2002-05-24 14:58 ` Alan Cox 2002-05-24 17:32 ` Thomas 'Dent' Mirlacher 0 siblings, 1 reply; 31+ messages in thread From: Alan Cox @ 2002-05-24 14:58 UTC (permalink / raw) To: Tobias Ringstrom; +Cc: Alan Cox, Myrddin Ambrosius, linux-kernel > On Wed, 22 May 2002, Alan Cox wrote: > > > What of it do you actually need in kernel space - encrypted file systems > > certainly ought to be there but are not very well handled in Linux proper > > right now - but anything else ? > > IPsec. At the moment there doesn't appear to be an IPsec stack we can merge however ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 14:58 ` Alan Cox @ 2002-05-24 17:32 ` Thomas 'Dent' Mirlacher 2002-05-24 17:21 ` David S. Miller 0 siblings, 1 reply; 31+ messages in thread From: Thomas 'Dent' Mirlacher @ 2002-05-24 17:32 UTC (permalink / raw) To: Alan Cox; +Cc: Tobias Ringstrom, Myrddin Ambrosius, linux-kernel On Fri, 24 May 2002, Alan Cox wrote: > > On Wed, 22 May 2002, Alan Cox wrote: > > > > > What of it do you actually need in kernel space - encrypted file systems > > > certainly ought to be there but are not very well handled in Linux proper > > > right now - but anything else ? > > > > IPsec. > > At the moment there doesn't appear to be an IPsec stack we can merge however what about freeswan - with some cleanups? tm -- in some way i do, and in some way i don't. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 17:32 ` Thomas 'Dent' Mirlacher @ 2002-05-24 17:21 ` David S. Miller 2002-05-24 17:42 ` Thomas 'Dent' Mirlacher 2002-05-24 21:49 ` Xavier Bestel 0 siblings, 2 replies; 31+ messages in thread From: David S. Miller @ 2002-05-24 17:21 UTC (permalink / raw) To: dent; +Cc: alan, tori, imipak, linux-kernel From: "Thomas 'Dent' Mirlacher" <dent@cosy.sbg.ac.at> Date: Fri, 24 May 2002 19:32:48 +0200 (MET DST) what about freeswan - with some cleanups? They won't let me (or any other US citizen) make any edits to any of the ipsec sources if it were to be added to the main tree. That's unacceptable because it means that effectively I cannot maintain the networking. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 17:21 ` David S. Miller @ 2002-05-24 17:42 ` Thomas 'Dent' Mirlacher 2002-05-24 17:31 ` David S. Miller 2002-05-24 18:41 ` Alan Cox 2002-05-24 21:49 ` Xavier Bestel 1 sibling, 2 replies; 31+ messages in thread From: Thomas 'Dent' Mirlacher @ 2002-05-24 17:42 UTC (permalink / raw) To: David S. Miller; +Cc: alan, tori, imipak, linux-kernel On Fri, 24 May 2002, David S. Miller wrote: > From: "Thomas 'Dent' Mirlacher" <dent@cosy.sbg.ac.at> > Date: Fri, 24 May 2002 19:32:48 +0200 (MET DST) > > what about freeswan - with some cleanups? > > They won't let me (or any other US citizen) make any edits to any of > the ipsec sources if it were to be added to the main tree. That's > unacceptable because it means that effectively I cannot maintain the > networking. well the _big_ thing the freeswan people are afraid of, is exactly the crypto laws in the us. - here is a proposal which should be acceptable (at least i hope so :) what about taking out the libdes stuff, and make it available from elsewhere, and hook it into the kernel as a module? the main kernel could come with a null crypto implementation - which makes no sense to use, but it will allow to meintain the whole system without having to worry about the crypto stuff per se (this shouldn't change very much in any case) any comments? tm -- in some way i do, and in some way i don't. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 17:42 ` Thomas 'Dent' Mirlacher @ 2002-05-24 17:31 ` David S. Miller 2002-05-24 17:57 ` Thomas 'Dent' Mirlacher 2002-05-24 18:41 ` Alan Cox 1 sibling, 1 reply; 31+ messages in thread From: David S. Miller @ 2002-05-24 17:31 UTC (permalink / raw) To: dent; +Cc: alan, tori, imipak, linux-kernel From: "Thomas 'Dent' Mirlacher" <dent@cosy.sbg.ac.at> Date: Fri, 24 May 2002 19:42:45 +0200 (MET DST) what about taking out the libdes stuff, and make it available from elsewhere, and hook it into the kernel as a module? the main kernel could come with a null crypto implementation - which makes no sense to use, but it will allow to meintain the whole system without having to worry about the crypto stuff per se (this shouldn't change very much in any case) The US laws cover even things that are meant to allow crypto. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 17:31 ` David S. Miller @ 2002-05-24 17:57 ` Thomas 'Dent' Mirlacher 2002-05-24 19:18 ` Myrddin Ambrosius 0 siblings, 1 reply; 31+ messages in thread From: Thomas 'Dent' Mirlacher @ 2002-05-24 17:57 UTC (permalink / raw) To: David S. Miller; +Cc: alan, tori, imipak, linux-kernel On Fri, 24 May 2002, David S. Miller wrote: > From: "Thomas 'Dent' Mirlacher" <dent@cosy.sbg.ac.at> > Date: Fri, 24 May 2002 19:42:45 +0200 (MET DST) > > what about taking out the libdes stuff, and make it available from > elsewhere, and hook it into the kernel as a module? > the main kernel could come with a null crypto implementation - which > makes no sense to use, but it will allow to meintain the whole system > without having to worry about the crypto stuff per se (this shouldn't > change very much in any case) > > The US laws cover even things that are meant to allow crypto. well, but if you take that by the word, is means you cannot export _any_ hooks from the kernel (like the sycall table), because it would enable someone to place some crytography in there (thinking of read and write calls) tm -- in some way i do, and in some way i don't. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 17:57 ` Thomas 'Dent' Mirlacher @ 2002-05-24 19:18 ` Myrddin Ambrosius 2002-05-25 4:01 ` Henrique de Moraes Holschuh 0 siblings, 1 reply; 31+ messages in thread From: Myrddin Ambrosius @ 2002-05-24 19:18 UTC (permalink / raw) To: Thomas 'Dent' Mirlacher, David S. Miller Cc: alan, tori, imipak, linux-kernel --- Thomas 'Dent' Mirlacher <dent@cosy.sbg.ac.at> wrote: > On Fri, 24 May 2002, David S. Miller wrote: > well, but if you take that by the word, is means you > cannot export _any_ > hooks from the kernel (like the sycall table), > because it would enable > someone to place some crytography in there (thinking > of read and write > calls) Shhhhh! The RIAA might be listening! :) Seriously, as I understand it, provided you register a site on which the source is located with two different House Of Spooks, then you're allowed to publish =ANY= cryptographic material, without restriction, and without further hastle. (I've read through the tediously long, archaic, English->Pig Latin documents on the EAR(?) website, decribing in nausiating detail exactly what is and is not permitted. However, I'd like it if someone else who has seen the documents could correct me if I'm wrong, as I think I fell asleep at several points.) __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 19:18 ` Myrddin Ambrosius @ 2002-05-25 4:01 ` Henrique de Moraes Holschuh 0 siblings, 0 replies; 31+ messages in thread From: Henrique de Moraes Holschuh @ 2002-05-25 4:01 UTC (permalink / raw) To: linux-kernel On Fri, 24 May 2002, Myrddin Ambrosius wrote: > not permitted. However, I'd like it if someone else > who has seen the documents could correct me if I'm > wrong, as I think I fell asleep at several points.) http://www.debian.org/legal/ -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 17:42 ` Thomas 'Dent' Mirlacher 2002-05-24 17:31 ` David S. Miller @ 2002-05-24 18:41 ` Alan Cox 2002-05-24 18:30 ` Thomas 'Dent' Mirlacher 2002-05-24 18:45 ` Herman Oosthuysen 1 sibling, 2 replies; 31+ messages in thread From: Alan Cox @ 2002-05-24 18:41 UTC (permalink / raw) To: Thomas 'Dent' Mirlacher Cc: David S. Miller, alan, tori, imipak, linux-kernel > > They won't let me (or any other US citizen) make any edits to any of > > the ipsec sources if it were to be added to the main tree. That's > > unacceptable because it means that effectively I cannot maintain the > > networking. > > well the _big_ thing the freeswan people are afraid of, is exactly the > crypto laws in the us. They refuse to have a US citizen working on it. Which is reasonable given the historu of US law, but until the US finishes outlawing computers in a couple of years that is a problem. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 18:41 ` Alan Cox @ 2002-05-24 18:30 ` Thomas 'Dent' Mirlacher 2002-05-24 18:55 ` Alan Cox 2002-05-24 20:17 ` Myrddin Ambrosius 2002-05-24 18:45 ` Herman Oosthuysen 1 sibling, 2 replies; 31+ messages in thread From: Thomas 'Dent' Mirlacher @ 2002-05-24 18:30 UTC (permalink / raw) To: Alan Cox; +Cc: David S. Miller, tori, imipak, linux-kernel On Fri, 24 May 2002, Alan Cox wrote: > > > They won't let me (or any other US citizen) make any edits to any of > > > the ipsec sources if it were to be added to the main tree. That's > > > unacceptable because it means that effectively I cannot maintain the > > > networking. > > > > well the _big_ thing the freeswan people are afraid of, is exactly the > > crypto laws in the us. > > They refuse to have a US citizen working on it. Which is reasonable given > the historu of US law, but until the US finishes outlawing computers in > a couple of years that is a problem. well probably everything which isn't plain english written with a pen on white paper would be outlawed by then ;) ... but what about having all the crypto stuff in question beeing handled by modules (developed outside the USSA) and having the networking-related code in the kernel - could the hooks itself be a problem? tm -- in some way i do, and in some way i don't. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 18:30 ` Thomas 'Dent' Mirlacher @ 2002-05-24 18:55 ` Alan Cox 2002-05-24 18:50 ` Sandy Harris 2002-05-29 0:24 ` Petro 2002-05-24 20:17 ` Myrddin Ambrosius 1 sibling, 2 replies; 31+ messages in thread From: Alan Cox @ 2002-05-24 18:55 UTC (permalink / raw) To: Thomas 'Dent' Mirlacher Cc: Alan Cox, David S. Miller, tori, imipak, linux-kernel > well probably everything which isn't plain english written with a pen > on white paper would be outlawed by then ;) > ... but what about having all the crypto stuff in question beeing handled > by modules (developed outside the USSA) and having the networking-related > code in the kernel - could the hooks itself be a problem? The US types really want to make that possibility exist. FreeSWAN put a huge amount of effort into their project. They don't want to make it possible for the US government to screw them around as well. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 18:55 ` Alan Cox @ 2002-05-24 18:50 ` Sandy Harris 2002-05-29 0:24 ` Petro 1 sibling, 0 replies; 31+ messages in thread From: Sandy Harris @ 2002-05-24 18:50 UTC (permalink / raw) To: linux-kernel; +Cc: hug Alan Cox wrote: > > > well probably everything which isn't plain english written with a pen > > on white paper would be outlawed by then ;) > > ... but what about having all the crypto stuff in question beeing handled > > by modules (developed outside the USSA) and having the networking-related > > code in the kernel - could the hooks itself be a problem? Any "crypto-shaped hole" -- any interface exclusively designed for crypto, or anything like a ipsec_init() call in the networking code -- is covered. A general-purpose interface is, theoretically at least, not covered. If the crypto plugs in to a standard kernel module interface, or to netfilter's interface for proxies and such, then the crypto code itself may still be restricted, but the kernel side code shouldn't be. > The US types really want to make that possibility exist. Yes, and the US gov't can change the rules. In particular, they might invent some interpretation that invalidates my second paragraph above and try to enforce it. > FreeSWAN put a huge amount of effort into their project. They don't > want to make it possible for the US government to screw them around > as well. This is a worthy and, given the history, quite likely a necessary goal. Most FreeS/WAN work has been done in Canada -- with contributions from many places, but no code from the US -- for exactly that reason. See discussion at: http://www.freeswan.org/freeswan_trees/freeswan-1.95/doc/politics.html#exlaw On the other hand, getting strong crypto -- including IPsec -- into the main kernel tree is also a thoroughly worthy goal. On yet another hand, it seems obviously reasonable for kernel maintainers not to accept code they cannot change. Is there any way to meet both goals? Would a BOF on the topic at OLS be useful? Here are my suggestions as posted to a couple of other lists a week or so ago. I don't imagine I have it right yet, but perhaps this would do as a starting point: Subject: [Design] Re: latest patches Date: Tue, 21 May 2002 14:59:06 -0700 From: Sandy Harris <sandy@storm.ca> To: linux-crypto@nl.linux.org CC: design@lists.freeswan.org, tytso@mit.edu Followup-To: linux-crypto@nl.linux.org In-Reply-To: <Pine.LNX.4.44.0205211623020.6721-100000@boris.prodako.se> <1021999182.2875.135.camel@janus.txd.hvrlab.org> [added cc to FreeS/WAN list and random.c author, and set followup-to] Herbert Valerio Riedel wrote: > > 1. Crypto support (no algorithms). This can go into the official kernel, > > at least once the API is stable. ... > > > 2. Crypto modules. Can probably not to inte the official kernel due to > > crypto export regulations. That doesn't work, at least not for US export regs. Any "crypto-shaped hole" -- any interface or plug-in support that is specifically for cryptography -- is restricted in exactly the same way as the crypto itself. However, if you use a generic multi-purpose interface, such as the Linux kernel modules interface or for IPsec, the interface that netfilter provides, then that interface is not restricted. Can the encrypted file system stuff use such an interface? Could FreeS/WAN? The good news about export regs is that, after two court losses in the Bernstein case (http://www.eff.org/bernstein/) the US gov't "liberalised" their regs so they now partially comply with the Wassenaar agreement (http://www.fitug.de/news/wa/index.html). That agreement says "public domain" code is exempt from its restrictions, period. Until Bernstein, the US ignored that and applied full restrictions. Now they only require notification for export of"public domain" source code. So under current regs, as long as kernel.org does some paperwork (which I think they have) there's no legal problem for crypto in the Linux kernel source. Of course, that does not cover US companies such as Redhat who might want to ship compliled code. It should, since the US has signed the Wassennaar agreement, but ... Also, it does not change the FreeS/WAN project's policy of carefully ensuring that their code is entirely developed outside the US so that even if the US gov't change the rules again, they cannot restrict FreeS/WAN. > some people also suggested splitting the ciphers up into > patented/non-patented, weak/strong, ... Why on Earth would you want either patented or weak ciphers? As I see it, you want only a very few ciphers, ideally only one. Simplicity is a great virtue in security software. Currently, I think the possible collection of crypto in the kernel is: drivers/char/random.c #define for either MD5 or SHA-1 MD4 for the TCP sequence # part ipsec both MD5 and SHA-1 3DES JuanJo's patches for ipsec AES cipher some of SHA-256, -384, -512 loop stuff multiple ciphers As far as I know, these are independent/duplicated. Many kernels will have two copies of MD5, one each in the random and ipsec code. If you use AES in both an encrypted file system and in IPsec, you'll have two copies (versions?) of the AES code. This is not a major problem, but it appears worth fixing. > > 3. Encrypted loop driver. > > > > What do you think? > good point... > > the crypto api itself almost kernel version independent, so it might > well justify splitting it from the cryptoloop application, which is the > biggest headache to keep in sync with the rest of the kernel... > > that's one of the reasons why I started to split off the loop-modifying > stuff into a patch of it's own (loop-jari/hvr patches)... > > now I'll just have to figure out a way to accomplish the split without > letting maintenance get unreasonable... I'd like to see, in the main kernel tree, one good hash and one good cipher. Then use them in all the above places. For AES in IPsec, the default (and the only required) algorithms are AES with 128-bit key and SHA-256. That makes them the obvious choices. You might want somewhat more than that. IPsec would probably want MD5, SHA-1 and 3DES for interoperability, RFC compliance and backward compatibility. I'd suggest the standard kernel not provide these. Keep them as part of FreeS/WAN so they cannot become "contaminated" with US code during kernel maintenance. I don't understand why random.c uses MD4; for all I know there are good reasons to keep it. There may be overhead issues. How fast is SHA-256 compared to MD5 and SHA-1? This mainly a concern for random.c. If you are doing AES, then it is likely both easy and a good idea to add Twofish and Serpent. These were final round AES candidate ciphers, so they've survived intensive analysis and there is code for them with the same interface as AES. Both have completely open licenses. If you're doing SHA-256, it may make sense to do SHA-384 and -512 as well. I think they use much the same code. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 18:55 ` Alan Cox 2002-05-24 18:50 ` Sandy Harris @ 2002-05-29 0:24 ` Petro 1 sibling, 0 replies; 31+ messages in thread From: Petro @ 2002-05-29 0:24 UTC (permalink / raw) To: linux-kernel On Fri, May 24, 2002 at 07:55:38PM +0100, Alan Cox wrote: > > well probably everything which isn't plain english written with a pen > > on white paper would be outlawed by then ;) > > ... but what about having all the crypto stuff in question beeing handled > > by modules (developed outside the USSA) and having the networking-related > > code in the kernel - could the hooks itself be a problem? > The US types really want to make that possibility exist. FreeSWAN put a > huge amount of effort into their project. They don't want to make it > possible for the US government to screw them around as well. They just have to understand that if we want to screw them around, we will, and International Law Be Damned. -- My last cigarette was roughly 36 days, 14 hours, 56 minutes ago. YHBW ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 18:30 ` Thomas 'Dent' Mirlacher 2002-05-24 18:55 ` Alan Cox @ 2002-05-24 20:17 ` Myrddin Ambrosius 2002-05-24 21:25 ` Thomas 'Dent' Mirlacher 1 sibling, 1 reply; 31+ messages in thread From: Myrddin Ambrosius @ 2002-05-24 20:17 UTC (permalink / raw) To: Thomas 'Dent' Mirlacher, Alan Cox Cc: David S. Miller, tori, imipak, linux-kernel --- Thomas 'Dent' Mirlacher <dent@cosy.sbg.ac.at> wrote: > well probably everything which isn't plain english > written with a pen > on white paper would be outlawed by then ;) Should be easy to test: if [ cat /usa/laws | grep ban | grep written | grep -q english ]; then echo "Ok, time to panic" fi Output: "You're too late. That's a $1000 fine, for using dictionary words." > ... but what about having all the crypto stuff in > question beeing handled > by modules (developed outside the USSA) and having > the networking-related > code in the kernel - could the hooks itself be a > problem? Hmmmm. This would be an interesting idea. In theory, I don't see why this couldn't be done via an extension of the existing network hooks. IIRC, there are hooks for adding new networking protocols, so it shouldn't be too difficult to extend this mechanism. What you'd need is the ability to layer one transport mechanism over another, as well as add them in parallel. That way, you're not adding hooks to be used -for- IPSec, merely hooks that IPSec could exploit. This could also be used to simplify the tunneling code. A tunnel would become an n-deep stack of transport mechanisms, each piping into the next. Instead of having to write a new tunneling system for every possible combination, you'd simply write your transport mechanism to support a "generic" input and "generic" output channel. Any protocol could then be tunelled through any other protocol, including a protocol which is already being used to tunnel. For IPSec, this translates to the transport mode becoming: network protocol -> IPSec And, for tunneling mode, you'd want something like: network protocol -> IPSec -> network protocol By allowing protocol stacks, and by having a generic interface, it would be easy to throw the output over a non-IP connection. At present, if you want to use IPSec over ATM, you'd need two tunnels. One for IPSec over IP, and one for IP over ATM. Each would need to be independently maintained, and you'd end up with a fascinating routing table, trying to get packets from one virtual device to another virtual device, through a virtual network space, without the router daemon deciding that what you REALLY want is some clam chowder. With the layering concept, you're simply wrapping one protocol in another, as many deep as you like, to produce a single, composite device, with the precice characteristics you want. For the IPSec over ATM, you've no tunnels, just the two wrappers (IP->IPSec, and IPSec->ATM), to produce a composite IP->IPSec->ATM virtual device. This is gettig WAAY too off-topic, at this point, but I could picture the protocols themselves being built up, LEGO-style, out of sub-components, both in parallel and as wrappers. The "standard" protocols would then be simply one way to wire the networking code, but there'd be a virtually infinite number of combinations you could do. (Most of those combinations would be meaningless, but could prove highly entertaining!) __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 20:17 ` Myrddin Ambrosius @ 2002-05-24 21:25 ` Thomas 'Dent' Mirlacher 0 siblings, 0 replies; 31+ messages in thread From: Thomas 'Dent' Mirlacher @ 2002-05-24 21:25 UTC (permalink / raw) To: Myrddin Ambrosius; +Cc: Alan Cox, David S. Miller, tori, linux-kernel --snip/snip > > ... but what about having all the crypto stuff in > > question beeing handled > > by modules (developed outside the USSA) and having > > the networking-related > > code in the kernel - could the hooks itself be a > > problem? > > Hmmmm. This would be an interesting idea. In theory, I > don't see why this couldn't be done via an extension > of the existing network hooks. > > IIRC, there are hooks for adding new networking > protocols, so it shouldn't be too difficult to extend > this mechanism. > > What you'd need is the ability to layer one transport > mechanism over another, as well as add them in > parallel. That way, you're not adding hooks to be used > -for- IPSec, merely hooks that IPSec could exploit. right - i was on the way looking into some "pluggable" system for the datalink layer in any case - and stumbled across other implementations: FreeBSDs netgraph, and also SysV streams. (i don't think netgraph works on layers >= network ... but that's another story) > This could also be used to simplify the tunneling > code. A tunnel would become an n-deep stack of > transport mechanisms, each piping into the next. well, you need also some hooks to hook into some arbitrary points in this "chain". - for setting up the tunnel, ... but yes, should be doable. > Instead of having to write a new tunneling system for > every possible combination, you'd simply write your > transport mechanism to support a "generic" input and > "generic" output channel. Any protocol could then be > tunelled through any other protocol, including a > protocol which is already being used to tunnel. right: for the datalink layer it your be decaps and encaps (or X_type_trans and hard_header right now) - looks a little bit different on higher layers. > For IPSec, this translates to the transport mode > becoming: network protocol -> IPSec > > And, for tunneling mode, you'd want something like: > network protocol -> IPSec -> network protocol seems to be ok (guess you just don't count DLL) > By allowing protocol stacks, and by having a generic > interface, it would be easy to throw the output over a > non-IP connection. since you should be able (at least in theory) to have deep nested stacks of protocols - including really ugly combinations > At present, if you want to use IPSec over ATM, you'd > need two tunnels. One for IPSec over IP, and one for > IP over ATM. Each would need to be independently > maintained, and you'd end up with a fascinating > routing table, trying to get packets from one virtual > device to another virtual device, through a virtual > network space, without the router daemon deciding that > what you REALLY want is some clam chowder. problem is: clam chowder is really tasty - but you cannot get it everywhere :) > With the layering concept, you're simply wrapping one > protocol in another, as many deep as you like, to > produce a single, composite device, with the precice > characteristics you want. For the IPSec over ATM, > you've no tunnels, just the two wrappers (IP->IPSec, > and IPSec->ATM), to produce a composite IP->IPSec->ATM > virtual device. yup. > This is gettig WAAY too off-topic, at this point, but > I could picture the protocols themselves being built > up, LEGO-style, out of sub-components, both in > parallel and as wrappers. The "standard" protocols > would then be simply one way to wire the networking > code, but there'd be a virtually infinite number of > combinations you could do. sure. - one thing which could get a little bit hairy are the combinations where: you have to setup the connection at some layer(s) connection orientated you'd like to have different addressed at different layers. but i guess you could use a userland tool for that. there is a streams implementation for linux out there (LiS), which could be capable of providing the above functionality - but i'm not aware of the performance impact. tm -- in some way i do, and in some way i don't. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 18:41 ` Alan Cox 2002-05-24 18:30 ` Thomas 'Dent' Mirlacher @ 2002-05-24 18:45 ` Herman Oosthuysen 1 sibling, 0 replies; 31+ messages in thread From: Herman Oosthuysen @ 2002-05-24 18:45 UTC (permalink / raw) To: linux-kernel Hmm, here is a brief policy statement on crypto in Canada. I know that this in not the US, but Canadian and US policies follow each other closely in military matters, due to various mutual defence agreements. From this, it is clear that most legal issues regarding the use/development of crypto has been dropped in North America. This makes sense, since it is far easier to gather intelligence by other means than by decrypting computer data. Instead of worrying about US law, you should now worry about French/Chinese/Russian law instead... --- SUMMARY OF CANADA'S CRYPTOGRAPHY POLICY BACKGROUNDER The Government is implementing a cryptography policy that: encourages the growth of electronic commerce; allows Canadian producers to export their products globally within the framework of international arrangements; and contains measures to maintain the capability of law enforcement agencies to ensure public safety. Support for Electronic Commerce Canadians are free to develop, import and use whatever cryptography products they wish. The Government will not implement mandatory key recovery requirements or licensing regimes. The Government encourages industry to establish responsible practices, such as key recovery techniques for stored data. The Government will act as a model user of cryptography through the practices of the Government of Canada Public Key Infrastructure (GOC PKI). The Government encourages and supports industry-led accreditation of private sector certification authorities. Export / International Agreements Canada will continue to implement cryptography export controls in keeping with the framework of the international Wassenaar Arrangement. Canada will take into consideration the export practices of other countries and the availability of comparable products when rendering export permit decisions. The export permit application process will be made more transparent and procedures will be streamlined to ensure the least regulatory intervention necessary. Public Safety The Government proposes amendments to the Criminal Code and other statutes as necessary to: criminalize the wrongful disclosure of keys; deter the use of encryption in the commission of a crime; deter the use of cryptography to conceal evidence; apply existing interception, search and seizure and assistance procedures to cryptographic situations and circumstances. --- Cheers, -- Herman Oosthuysen Herman@WirelessNetworksInc.com Suite 300, #3016, 5th Ave NE, Calgary, Alberta, T2A 6K4, Canada Phone: (403) 569-5687, Fax: (403) 235-3965 ----- Original Message ----- From: Alan Cox <alan@lxorguk.ukuu.org.uk> To: Thomas 'Dent' Mirlacher <dent@cosy.sbg.ac.at> Cc: David S. Miller <davem@redhat.com>; <alan@lxorguk.ukuu.org.uk>; <tori@ringstrom.mine.nu>; <imipak@yahoo.com>; <linux-kernel@vger.kernel.org> Sent: Friday, May 24, 2002 12:41 PM Subject: Re: Linux crypto? > > > They won't let me (or any other US citizen) make any edits to any of > > > the ipsec sources if it were to be added to the main tree. That's > > > unacceptable because it means that effectively I cannot maintain the > > > networking. > > > > well the _big_ thing the freeswan people are afraid of, is exactly the > > crypto laws in the us. > > They refuse to have a US citizen working on it. Which is reasonable given > the historu of US law, but until the US finishes outlawing computers in > a couple of years that is a problem. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 17:21 ` David S. Miller 2002-05-24 17:42 ` Thomas 'Dent' Mirlacher @ 2002-05-24 21:49 ` Xavier Bestel 2002-05-24 21:43 ` David S. Miller 2002-06-18 15:06 ` Drivers, Hardware, and their relationship to Bagels Myrddin Ambrosius 1 sibling, 2 replies; 31+ messages in thread From: Xavier Bestel @ 2002-05-24 21:49 UTC (permalink / raw) To: David S. Miller; +Cc: dent, Alan Cox, tori, imipak, Linux Kernel Mailing List Le ven 24/05/2002 à 19:21, David S. Miller a écrit : > From: "Thomas 'Dent' Mirlacher" <dent@cosy.sbg.ac.at> > Date: Fri, 24 May 2002 19:32:48 +0200 (MET DST) > > what about freeswan - with some cleanups? > > They won't let me (or any other US citizen) make any edits to any of > the ipsec sources if it were to be added to the main tree. That's > unacceptable because it means that effectively I cannot maintain the > networking. Why ? You can make all edits you like, they just won't be folded back to their tree. You can retrieve all their fixes, just if you have an important change to do in their core, do it as free speech on their public mailing list, do not provide a patch. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 21:49 ` Xavier Bestel @ 2002-05-24 21:43 ` David S. Miller 2002-05-26 10:06 ` Jakob Østergaard 2002-06-18 15:06 ` Drivers, Hardware, and their relationship to Bagels Myrddin Ambrosius 1 sibling, 1 reply; 31+ messages in thread From: David S. Miller @ 2002-05-24 21:43 UTC (permalink / raw) To: xavier.bestel; +Cc: dent, alan, tori, imipak, linux-kernel From: Xavier Bestel <xavier.bestel@free.fr> Date: 24 May 2002 23:49:29 +0200 Why ? You can make all edits you like, they just won't be folded back to their tree. You can retrieve all their fixes, just if you have an important change to do in their core, do it as free speech on their public mailing list, do not provide a patch. I can't edit their code because effectively I could contaminate their sources. Say I make some global networking API change, and this required a significant edit to ipsec to make it comply with the new structure layout or whatever. And let's assume there is only one clear way to implement the change, no other way to do the change would make any sense at all. So the IPSEC people would have to effectively avoid integrating my change, ie. it is a big onus on them to make their version of the API update different enough from my edits so that nobody can claim they just applied my change. And the fact that there would be two edits makes no sense. If a change has to occur twice in two different ways this makes merging a disaster. So someone quips "just let them edit and just merge from IPSEC" and I say I refuse to let something just sit in the tree that I cannot edit when I want to make sweeping changes across the tree. That is unacceptable. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Linux crypto? 2002-05-24 21:43 ` David S. Miller @ 2002-05-26 10:06 ` Jakob Østergaard 0 siblings, 0 replies; 31+ messages in thread From: Jakob Østergaard @ 2002-05-26 10:06 UTC (permalink / raw) To: David S. Miller; +Cc: xavier.bestel, dent, alan, tori, imipak, linux-kernel On Fri, May 24, 2002 at 02:43:05PM -0700, David S. Miller wrote: > From: Xavier Bestel <xavier.bestel@free.fr> > Date: 24 May 2002 23:49:29 +0200 > > Why ? You can make all edits you like, they just won't be folded back to > their tree. You can retrieve all their fixes, just if you have an > important change to do in their core, do it as free speech on their > public mailing list, do not provide a patch. > > I can't edit their code because effectively I could contaminate > their sources. Could there be issued a general license for export of the Linux kernel from the U.S. ? It seems that even though the politics/politicians may not be entirely up to par with reality, that there is also some understanding of the need to share and cooperate in development of a secure operating system kernel. Most notably, the NSA Secure Linux Project. While this doesn't include crypto, it includes a number of other technologies which are (like crypto) necessary for a secure environment, but (like crypto) not any magic secret technology that it would make sense to restrict exports on. Could someone from "inside" give an oppinion on this ? As far as I know, it should be possible to get a general license for the export of the Linux kernel (by some definition thereof). It works like this in my country too, and probably many others. If this could be done with the U.S. perhaps other countries with export/import controls would be more willing to negotiatiate similar deals. "First we take Manhattan, then we take Berlin" ;) -- ................................................................ : jakob@unthought.net : And I see the elder races, : :.........................: putrid forms of man : : Jakob Østergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............: ^ permalink raw reply [flat|nested] 31+ messages in thread
* Drivers, Hardware, and their relationship to Bagels. 2002-05-24 21:49 ` Xavier Bestel 2002-05-24 21:43 ` David S. Miller @ 2002-06-18 15:06 ` Myrddin Ambrosius 2002-06-18 15:01 ` Zwane Mwaikambo ` (2 more replies) 1 sibling, 3 replies; 31+ messages in thread From: Myrddin Ambrosius @ 2002-06-18 15:06 UTC (permalink / raw) To: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1536 bytes --] Hi all, With the discussion on kernel crypto a while back, there was one very important recurring element that I would like someone to clarify for me. The issue is this. My understanding is that -all- hardware access should be through the kernel, partly so that similar hardware can have a similar API, but also so that kernel security code (eg: capabilities) applies to ALL hardware and ALL lower-level operations. However, there were a number of mentions of userland hardware drivers, which did NOT operate through the kernel. (This was in reference to why it wouldn't be necessary to have a kernel-level driver for the Motorola M190 crypto chip.) If you can blithely ignore restrictions placed by the kernel on some piece of hardware, and access it directly, then surely this would apply to any hardware. Including disk drives, RAM, etc. I could be wrong (and I hope, very much, that I am), but if my understanding is correct, then that's a hole you could drive a truck through, and have room to spare. This isn't intended as a critisism of anyone, or of any decisions made regarding the way the kernel operates. (I know my phrasing leaves a lot to be desired. Sometimes I think my best chance of a long life would be to take a vow of silence and become a monk.) I'd really appreciate it if someone could clarify this for me, especially the security aspect of non-kernel drivers. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com [-- Attachment #2: ks.txt --] [-- Type: text/plain, Size: 489 bytes --] (Tune of "Running Free", by Iron Maiden) Kernel bug, core runs wild, Space/time twists and gets compiled. Wormholes open and bring to me, Linux Kernel Version 3! I'm running 3, yeah, I'm running 3! I'm running 3, yeah, I'm running 3! Got support for Tbyte RAM, The newest arch is leg of lamb. Max cpus, one thousand now, Neg latency gives quite a pow. Men in Black zap my brains, Melt the hard-disk, and what remains. There's nothing left for you to see That my machine was running 3! ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Drivers, Hardware, and their relationship to Bagels. 2002-06-18 15:06 ` Drivers, Hardware, and their relationship to Bagels Myrddin Ambrosius @ 2002-06-18 15:01 ` Zwane Mwaikambo 2002-06-18 15:26 ` Richard B. Johnson 2002-06-18 16:01 ` Xavier Bestel 2 siblings, 0 replies; 31+ messages in thread From: Zwane Mwaikambo @ 2002-06-18 15:01 UTC (permalink / raw) To: Myrddin Ambrosius; +Cc: linux-kernel On Tue, 18 Jun 2002, Myrddin Ambrosius wrote: > If you can blithely ignore restrictions placed by the > kernel on some piece of hardware, and access it > directly, then surely this would apply to any > hardware. Including disk drives, RAM, etc. iopl(2), chmod(1) and friends, hardware frobbing isn't a free for all. Then again if you're root... Regards, Zwane Mwaikambo -- http://function.linuxpower.ca ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Drivers, Hardware, and their relationship to Bagels. 2002-06-18 15:06 ` Drivers, Hardware, and their relationship to Bagels Myrddin Ambrosius 2002-06-18 15:01 ` Zwane Mwaikambo @ 2002-06-18 15:26 ` Richard B. Johnson 2002-06-18 18:35 ` Myrddin Ambrosius 2002-06-18 16:01 ` Xavier Bestel 2 siblings, 1 reply; 31+ messages in thread From: Richard B. Johnson @ 2002-06-18 15:26 UTC (permalink / raw) To: Myrddin Ambrosius; +Cc: linux-kernel On Tue, 18 Jun 2002, Myrddin Ambrosius wrote: > Hi all, > > With the discussion on kernel crypto a while back, > there was one very important recurring element that I > would like someone to clarify for me. > > The issue is this. My understanding is that -all- > hardware access should be through the kernel, partly > so that similar hardware can have a similar API, but > also so that kernel security code (eg: capabilities) > applies to ALL hardware and ALL lower-level > operations. > > However, there were a number of mentions of userland > hardware drivers, which did NOT operate through the > kernel. (This was in reference to why it wouldn't be > necessary to have a kernel-level driver for the > Motorola M190 crypto chip.) > > If you can blithely ignore restrictions placed by the > kernel on some piece of hardware, and access it > directly, then surely this would apply to any > hardware. Including disk drives, RAM, etc. > > I could be wrong (and I hope, very much, that I am), > but if my understanding is correct, then that's a hole > you could drive a truck through, and have room to > spare. > > This isn't intended as a critisism of anyone, or of > any decisions made regarding the way the kernel > operates. (I know my phrasing leaves a lot to be > desired. Sometimes I think my best chance of a long > life would be to take a vow of silence and become a > monk.) > > I'd really appreciate it if someone could clarify this > for me, especially the security aspect of non-kernel > drivers. No hole you can drive through. A process with a UID of 0 and a GID of 0 can do anything it wants. It can execute iopl(3) and set an I/O permission level that allows it to directly access hardware I/O ports, etc. It can also turn off interrupts. Basically, it can do anything, since such a process can also memory-map anything. Users are not supposed to execute as 'root'. Also, only certain priviliged tasks execute as root. Ignore that this account "seems-to-be" root@chaos.analogic.com. This is an anti-spam trick. The real root on this machine is called "system". Names mean nothing to Unix, it's the UID/GID that counts. You can make a priviliged task by setting the UID/GID to zero in the first few lines of 'C' code of main(). This will fail unless the resulting executable has its SUID bit set (chmod 4755 filename). Further, this file has to execute in a root-owned directory. Once these conditions are satisfied, the program can do anything it wants. main() { setuid(0); setgid(0); iopl(3); mmap(everything); destroy_the_world(); } Cheers, Dick Johnson Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Windows-2000/Professional isn't. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Drivers, Hardware, and their relationship to Bagels. 2002-06-18 15:26 ` Richard B. Johnson @ 2002-06-18 18:35 ` Myrddin Ambrosius 2002-06-18 19:13 ` Richard B. Johnson 2002-06-19 2:11 ` Stevie O 0 siblings, 2 replies; 31+ messages in thread From: Myrddin Ambrosius @ 2002-06-18 18:35 UTC (permalink / raw) To: root; +Cc: linux-kernel --- "Richard B. Johnson" <root@chaos.analogic.com> wrote: > No hole you can drive through. A process with a UID > of 0 and > a GID of 0 can do anything it wants. It can execute > iopl(3) > and set an I/O permission level that allows it to > directly access > hardware I/O ports, etc. It can also turn off > interrupts. Basically, > it can do anything, since such a process can also > memory-map anything. But since it is the kernel that permits that (by definition, since somebody has to check the UID & GID! :) then the kernel can also restrict that. The system admin account (UID/GID 0) could just as easily access a virtual memory map, virtual I/O ports, etc, with the kernel then handling how that maps onto the physical world, and even IF it does. > Users are not supposed to execute as 'root'. Also, > only certain > priviliged tasks execute as root. Ignore that this The problem with priviliged tasks is that (in general) they run with absolute privilige. Sure, some of these priviliges can be turned off, but if /dev/mem is reachable, then they can be turned back on again, precicely for the reasons you give. I guess that my understanding for having kernels the size and complexity of Linux, as opposed to, say, CP/M, is that the kernel can reduce the need for userspace apps to have dangerous powers. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Drivers, Hardware, and their relationship to Bagels. 2002-06-18 18:35 ` Myrddin Ambrosius @ 2002-06-18 19:13 ` Richard B. Johnson 2002-06-19 2:11 ` Stevie O 1 sibling, 0 replies; 31+ messages in thread From: Richard B. Johnson @ 2002-06-18 19:13 UTC (permalink / raw) To: Myrddin Ambrosius; +Cc: linux-kernel On Tue, 18 Jun 2002, Myrddin Ambrosius wrote: > > I guess that my understanding for having kernels the > size and complexity of Linux, as opposed to, say, > CP/M, is that the kernel can reduce the need for > userspace apps to have dangerous powers. Users need to have 'dangerous' things done, like reading and writing to hard-disks, etc. To keep things organized, like writing and reading files they control, there is some code called the kernel, that performs these 'dangerous' things on behalf of the callers. Since the callers can't modify the kernel to make it do "bad" things like writing outside "files", everything works out just fine. The exact same things can usually be done by "user-mode" programs. You just need to keep them from being hacked and everything works out just fine, just like in the kernel. Cheers, Dick Johnson Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Windows-2000/Professional isn't. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Drivers, Hardware, and their relationship to Bagels. 2002-06-18 18:35 ` Myrddin Ambrosius 2002-06-18 19:13 ` Richard B. Johnson @ 2002-06-19 2:11 ` Stevie O 1 sibling, 0 replies; 31+ messages in thread From: Stevie O @ 2002-06-19 2:11 UTC (permalink / raw) To: Myrddin Ambrosius, root; +Cc: linux-kernel At 11:35 AM 6/18/2002 -0700, Myrddin Ambrosius wrote: >The problem with priviliged tasks is that (in general) >they run with absolute privilige. Sure, some of these >priviliges can be turned off, but if /dev/mem is >reachable, then they can be turned back on again, >precicely for the reasons you give. What about the bagels? I like bagels! ;) I agree that this is a problem. A very, very good example of this is 'binding to a reserved port (<1024)'. A number of programs that should never need to run as root, do, some for the sole purpose of binding to a "reserved port": * Webservers in a relatively simple configuration (ex: my Apache install) * BIND (which doesn't even drop root. A security nightmare.) * identd There are kernel patches that can help solve this problem. One, found at ftp://ftp.v-lo.krakow.pl/pub/linux/patches/, creates 'magic' GIDs that give special limited privileges like binding to a reserved port (above list) or creating a raw socket (ping, traceroute). If I recall the Capabilities FAQ correctly, I think there's something relating to PAM that might let you give partial capabilities to certain users who login (like CAP_SYS_TIME to your normal desktop login, so you can set the clock without using 'su'). It would be nice to be able to (relatively easily) create certain uids/gids (or names) that get special privileges automatically... then certain apps (like ping, traceroute) could be setuid something-less-powerful-than-root. I think that'd be an interesting project to work on when I'm bored... anybody on this list think it's worthy of discussion (or not worthy -- arguing is fun, it makes for more active threads!) ? Just remember -- we need root/uid0/whatever, because in the end, the computers are here to serve US, to do OUR bidding. And using root is what I like to term an 'executive override' -- it cuts through all the protections and guards that the kernel has, and makes the computer do what we say. That's why we don't protect root from itself. -- Stevie-O Real programmers use COPY CON PROGRAM.EXE ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Drivers, Hardware, and their relationship to Bagels. 2002-06-18 15:06 ` Drivers, Hardware, and their relationship to Bagels Myrddin Ambrosius 2002-06-18 15:01 ` Zwane Mwaikambo 2002-06-18 15:26 ` Richard B. Johnson @ 2002-06-18 16:01 ` Xavier Bestel 2002-06-18 18:23 ` Myrddin Ambrosius 2 siblings, 1 reply; 31+ messages in thread From: Xavier Bestel @ 2002-06-18 16:01 UTC (permalink / raw) To: Myrddin Ambrosius; +Cc: Linux Kernel Mailing List Le mar 18/06/2002 à 17:06, Myrddin Ambrosius a écrit : > The issue is this. My understanding is that -all- > hardware access should be through the kernel, partly > so that similar hardware can have a similar API, but > also so that kernel security code (eg: capabilities) > applies to ALL hardware and ALL lower-level > operations. You want to forbid XFree86's DRI ? Xav ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Drivers, Hardware, and their relationship to Bagels. 2002-06-18 16:01 ` Xavier Bestel @ 2002-06-18 18:23 ` Myrddin Ambrosius 0 siblings, 0 replies; 31+ messages in thread From: Myrddin Ambrosius @ 2002-06-18 18:23 UTC (permalink / raw) To: Xavier Bestel; +Cc: Linux Kernel Mailing List [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 4009 bytes --] --- Xavier Bestel <xavier.bestel@free.fr> wrote: > Le mar 18/06/2002 à 17:06, Myrddin Ambrosius a écrit > : > > The issue is this. My understanding is that -all- > > hardware access should be through the kernel, > partly > > so that similar hardware can have a similar API, > but > > also so that kernel security code (eg: > capabilities) > > applies to ALL hardware and ALL lower-level > > operations. > > You want to forbid XFree86's DRI ? No, the kernel's DRM provides a nice kernel layer for XFree's DRI, which covers all the security issues. Well, provided the DRM code gets enough drivers. Personally, I'd like to see more fine-control of graphics hardware end up in the kernel, partly to avoid some of the nastier security risks (such as having to run X servers as root! bleagh!) but also because the kernel has to have a whole lot of control anyway. The sheer number of possible displays you can put into any given one of the fantastically large number of virtual consoles makes for an interesting challange. (On older kernels, changing to and from virtual terminal when running an svgalib app could do some VERY interesting things to your display.) When you start looking at running X under multiple resolutions on the same machine, or even running multiple X servers (which I -think- is now possible), things don't get any better. If the kernel's various graphics components (DRM, framebuffers, etc) handled the low-level stuff, you don't get multiple pieces of software each trying to drive the screen at a different rate. You could even have two pieces of software access the same virtual terminal at different resolutions, because the kernel would eliminate the "conflict". I understand that, prior to framebuffers going in, there were a number of (cough!) lengthy discussions on the safety and stability of high-level code in the kernel. I honestly believe that this is the flip-side of that same debate. Whether it is safe and stable to have low-level code in userland. I honestly believe that too much low-level code or access in userland is just as destabilizing (and potentially far more dangerous) than high-level code in the kernel. Someone else mentioned all the wonderful stuff root can do. Root's a cool toy, but in the end, root is still a product of the kernel's imagination. There is no physical chunk of machinary in a computer that can be called "root". Unless your spider-plant has grown. Therefore, to argue that root can do anything is not entirely true. (In fact, Linux' Capabilities demonstrates this, nicely. It is possible to set the capabilities such that nothing root can do can re-enable any capabilities removed.) It would be too soon to "retire" root, because I don't think anyone's entirely happy with the alternatives that exist. (If they were, Linux would have lost root before version 1.0! I can remember patches almost the size of the kernel!) Maybe, someday, someone'll figure out a rootless system that is generally acceptable. On the other hand, if the small handful of actual instructions (not apps, not even functions, just the instructions) that -need- super-user privs were all encapsulated inside kernel system calls, then you don't risk running a root-kit-o-matic every time you boot X, or some other server that currently needs root privs. One reason for NOT doing this is that it takes time to switch between contexts. Deliberately adding a whole bunch of switches would seem to be remarkably stupid. Doubly so, when you're adding switches to maybe run half a dozen lines. For stuff that's used heavily, there's probably less time penalty in typing the code in by hand into the server, and running as root, than all the constant switching. I don't have to like it, but I can't find any solid argument against this. Good solutions are efficient, and efficient != slower than a snail on salt. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2002-06-19 2:18 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-05-22 18:03 Linux crypto? Myrddin Ambrosius 2002-05-22 18:38 ` Alan Cox 2002-05-23 8:45 ` Trond Myklebust 2002-05-23 21:46 ` Tobias Ringstrom 2002-05-24 14:58 ` Alan Cox 2002-05-24 17:32 ` Thomas 'Dent' Mirlacher 2002-05-24 17:21 ` David S. Miller 2002-05-24 17:42 ` Thomas 'Dent' Mirlacher 2002-05-24 17:31 ` David S. Miller 2002-05-24 17:57 ` Thomas 'Dent' Mirlacher 2002-05-24 19:18 ` Myrddin Ambrosius 2002-05-25 4:01 ` Henrique de Moraes Holschuh 2002-05-24 18:41 ` Alan Cox 2002-05-24 18:30 ` Thomas 'Dent' Mirlacher 2002-05-24 18:55 ` Alan Cox 2002-05-24 18:50 ` Sandy Harris 2002-05-29 0:24 ` Petro 2002-05-24 20:17 ` Myrddin Ambrosius 2002-05-24 21:25 ` Thomas 'Dent' Mirlacher 2002-05-24 18:45 ` Herman Oosthuysen 2002-05-24 21:49 ` Xavier Bestel 2002-05-24 21:43 ` David S. Miller 2002-05-26 10:06 ` Jakob Østergaard 2002-06-18 15:06 ` Drivers, Hardware, and their relationship to Bagels Myrddin Ambrosius 2002-06-18 15:01 ` Zwane Mwaikambo 2002-06-18 15:26 ` Richard B. Johnson 2002-06-18 18:35 ` Myrddin Ambrosius 2002-06-18 19:13 ` Richard B. Johnson 2002-06-19 2:11 ` Stevie O 2002-06-18 16:01 ` Xavier Bestel 2002-06-18 18:23 ` Myrddin Ambrosius
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).