* Linuxfromscratch.org @ 2003-07-22 1:42 Charlie Watts 2003-07-22 20:06 ` Linuxfromscratch.org Russell Coker 0 siblings, 1 reply; 24+ messages in thread From: Charlie Watts @ 2003-07-22 1:42 UTC (permalink / raw) To: selinux I want to make a linux system from scratch. I have never compiled my own kernel, but I was wondering if i could start with the SE Linux kernel. I am using the instructions from linuxfromscratch.org to make the system on my laptop, which is running Mandrake 9, on a i686, 512Mb ram, and a 1.13 GHz P IV. Ext3 file system. Any advice would be great. Thank you Charlie __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-22 1:42 Linuxfromscratch.org Charlie Watts @ 2003-07-22 20:06 ` Russell Coker 2003-07-22 20:49 ` Linuxfromscratch.org Dean Anderson 2003-07-23 1:17 ` Linuxfromscratch.org Carsten P. Gehrke 0 siblings, 2 replies; 24+ messages in thread From: Russell Coker @ 2003-07-22 20:06 UTC (permalink / raw) To: Charlie Watts, selinux On Mon, 21 Jul 2003 21:42, Charlie Watts wrote: > I want to make a linux system from scratch. I have never compiled my > own kernel, but I was wondering if i could start with the SE Linux > kernel. I am using the instructions from linuxfromscratch.org to make > the system on my laptop, which is running Mandrake 9, on a i686, 512Mb > ram, and a 1.13 GHz P IV. Ext3 file system. Any advice would be great. I recommend that you compile your own kernel without SE Linux first, and then try using SE Linux after you have had some practise at building your own kernel. Otherwise if you have a problem you won't know whether it's SE Linux related or just a general kernel build issue. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-22 20:06 ` Linuxfromscratch.org Russell Coker @ 2003-07-22 20:49 ` Dean Anderson 2003-07-23 15:09 ` Linuxfromscratch.org Carsten P. Gehrke 2003-07-23 1:17 ` Linuxfromscratch.org Carsten P. Gehrke 1 sibling, 1 reply; 24+ messages in thread From: Dean Anderson @ 2003-07-22 20:49 UTC (permalink / raw) To: Russell Coker; +Cc: Charlie Watts, selinux if you are looking for integrity, Linuxfromscratch is just the start. You have to come up with a way to exclude Kerningan-style compiler hacks, and similar OS hacks from being inserted into the "clean" source build. Kernigan, as some will remember, early in Unix days (70s), altered the compiler to include a backdoor in login when it compiled login.c, and altered the compiler to insert the backdoor-inserter whenever it compiled itself. So even if you recompiled Unix from scratch from clean source, you still had a backdoor. I think even if you retargeted the compiler, it still inserted to the apprpropriate backdoor-inserter. A similar hack can be done at the OS level. --Dean On Tue, 22 Jul 2003, Russell Coker wrote: > On Mon, 21 Jul 2003 21:42, Charlie Watts wrote: > > I want to make a linux system from scratch. I have never compiled my > > own kernel, but I was wondering if i could start with the SE Linux > > kernel. I am using the instructions from linuxfromscratch.org to make > > the system on my laptop, which is running Mandrake 9, on a i686, 512Mb > > ram, and a 1.13 GHz P IV. Ext3 file system. Any advice would be great. > > I recommend that you compile your own kernel without SE Linux first, and then > try using SE Linux after you have had some practise at building your own > kernel. Otherwise if you have a problem you won't know whether it's SE Linux > related or just a general kernel build issue. > > -- > http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages > http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark > http://www.coker.com.au/postal/ Postal SMTP/POP benchmark > http://www.coker.com.au/~russell/ My home page > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-22 20:49 ` Linuxfromscratch.org Dean Anderson @ 2003-07-23 15:09 ` Carsten P. Gehrke 2003-07-23 15:44 ` Linuxfromscratch.org Russell Coker ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Carsten P. Gehrke @ 2003-07-23 15:09 UTC (permalink / raw) To: Dean Anderson, Russell Coker; +Cc: Charlie Watts, selinux At 13:49 22-07-03, Dean Anderson wrote: >if you are looking for integrity, Linuxfromscratch is just the start. > >You have to come up with a way to exclude Kerningan-style compiler hacks, >and similar OS hacks from being inserted into the "clean" source build. > >Kernigan, as some will remember, early in Unix days (70s), altered the >compiler to include a backdoor in login when it compiled login.c, and >altered the compiler to insert the backdoor-inserter whenever it compiled >itself. So even if you recompiled Unix from scratch from clean source, >you still had a backdoor. I think even if you retargeted the compiler, it >still inserted to the apprpropriate backdoor-inserter. A similar hack can >be done at the OS level. > > --Dean Is this true of the GNU C compiler suite as well? And if so, would it not be possible to remove it from the compiler? How does it work? Does it look at the code, or is anything called login.c susceptible? Why has this not been removed in the open-source code? How can I check to see if this backdoor exists? TIA, Carsten -- ======================================================================== Carsten P. Gehrke mailto:Carsten@RollingHorse.com ======================================================================== -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-23 15:09 ` Linuxfromscratch.org Carsten P. Gehrke @ 2003-07-23 15:44 ` Russell Coker 2003-07-23 20:01 ` Linuxfromscratch.org Dale Amon 2003-07-23 21:24 ` Linuxfromscratch.org Dean Anderson 2003-07-23 19:34 ` Linuxfromscratch.org karlm 2003-07-23 20:26 ` Linuxfromscratch.org Lukasz Luzar 2 siblings, 2 replies; 24+ messages in thread From: Russell Coker @ 2003-07-23 15:44 UTC (permalink / raw) To: Carsten P. Gehrke; +Cc: selinux On Wed, 23 Jul 2003 11:09, Carsten P. Gehrke wrote: > Is this true of the GNU C compiler suite as well? And if so, would it not > be possible to remove it from the compiler? How does it work? Does it > look at the code, or is anything called login.c susceptible? Why has this > not been removed in the open-source code? How can I check to see if this > backdoor exists? This is not in the current GCC builds, if it ever was. There are a variety of stories concerning this, some say that it was just commented code to illustrate a point, some say that it was in there with full nasty capabilities but was removed years ago (>10 years). There is no need to worry about this particular exploit right now, but there are issues with the potential for creating others of the same type. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-23 15:44 ` Linuxfromscratch.org Russell Coker @ 2003-07-23 20:01 ` Dale Amon 2003-07-23 21:24 ` Linuxfromscratch.org Dean Anderson 1 sibling, 0 replies; 24+ messages in thread From: Dale Amon @ 2003-07-23 20:01 UTC (permalink / raw) To: Russell Coker; +Cc: Carsten P. Gehrke, selinux On Wed, Jul 23, 2003 at 11:44:38AM -0400, Russell Coker wrote: > There are a variety of stories concerning this, some say that it was just > commented code to illustrate a point, some say that it was in there with full > nasty capabilities but was removed years ago (>10 years). I know he did a paper on it, I'm not sure it was actually implimented. Btw Russ... did you get my email or did it get stuck in your spam traps? -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-23 15:44 ` Linuxfromscratch.org Russell Coker 2003-07-23 20:01 ` Linuxfromscratch.org Dale Amon @ 2003-07-23 21:24 ` Dean Anderson 1 sibling, 0 replies; 24+ messages in thread From: Dean Anderson @ 2003-07-23 21:24 UTC (permalink / raw) To: Russell Coker; +Cc: Carsten P. Gehrke, selinux Technically, we can only say we don't know that it is in the GCC builds. But we also get compilers and operating systems from many places. The Kernigan hack predated GCC, and the GNU project, which was only started after Stallmen reverse engineered the password encryption algorithm, and was barred from ATT source code. It also predates my active involvement, so I can't say if it actually happened or if it was just documented as possible. The way it has been passed to me is that it actually happened, and was distributed--though this was pre-commercialization/pre SysV. The only way to check for it would be to decompile code with a tool that wasn't altered to remove the evidence--note that it is hard to be too paranoid when you really start to think about the possibilities. It is tremendously hard to have truly trustworthy tools. Shared libraries and loadable modules make this even harder today, since the trusted executable may load untrusted shared libraries, or system calls may be altered (as some root kits actually do). I do recall in the OSF/1 B1 secure effort (though memory fades) that if one had kernel loader privilege, one could subvert all other privileges and thereby defeat the B1 requirement of separate roles/privileges. I recall that it was thought that no system with loadable kernel modules could ever be B1 secure, unless it was based on a trusted microkernel, which only loaded additional personality modules which would be unable to alter certain security functions. (Unix being a personality module). The OSF also had a research effort in micro kernels, based on Mach, and had a working OSF/1 personality for it, but the personality was never shipped. --Dean P.S. It still seems that Russell Coker has some overzealous antispam measures, which violate the email ethics standards promoted by the EFF. http://www.eff.org/Spam_cybersquatting_abuse/Spam/position_on_junk_email.html On Wed, 23 Jul 2003, Russell Coker wrote: > On Wed, 23 Jul 2003 11:09, Carsten P. Gehrke wrote: > > Is this true of the GNU C compiler suite as well? And if so, would it not > > be possible to remove it from the compiler? How does it work? Does it > > look at the code, or is anything called login.c susceptible? Why has this > > not been removed in the open-source code? How can I check to see if this > > backdoor exists? > > This is not in the current GCC builds, if it ever was. > > There are a variety of stories concerning this, some say that it was just > commented code to illustrate a point, some say that it was in there with full > nasty capabilities but was removed years ago (>10 years). > > There is no need to worry about this particular exploit right now, but there > are issues with the potential for creating others of the same type. > > -- > http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages > http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark > http://www.coker.com.au/postal/ Postal SMTP/POP benchmark > http://www.coker.com.au/~russell/ My home page > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-23 15:09 ` Linuxfromscratch.org Carsten P. Gehrke 2003-07-23 15:44 ` Linuxfromscratch.org Russell Coker @ 2003-07-23 19:34 ` karlm 2003-07-23 22:08 ` Linuxfromscratch.org Dean Anderson ` (2 more replies) 2003-07-23 20:26 ` Linuxfromscratch.org Lukasz Luzar 2 siblings, 3 replies; 24+ messages in thread From: karlm @ 2003-07-23 19:34 UTC (permalink / raw) To: Carsten P. Gehrke Cc: Dean Anderson, Russell Coker, Charlie Watts, selinux, karlm >At 13:49 22-07-03, Dean Anderson wrote: >>if you are looking for integrity, Linuxfromscratch is just the start. >> >>You have to come up with a way to exclude Kerningan-style compiler hacks, >>and similar OS hacks from being inserted into the "clean" source build. >> >>Kernigan, as some will remember, early in Unix days (70s), altered the >>compiler to include a backdoor in login when it compiled login.c, and >>altered the compiler to insert the backdoor-inserter whenever it compiled >>itself. So even if you recompiled Unix from scratch from clean source, >>you still had a backdoor. I think even if you retargeted the compiler, it >>still inserted to the apprpropriate backdoor-inserter. A similar hack can >>be done at the OS level. >> >> --Dean > >Is this true of the GNU C compiler suite as well? And if so, would it not >be possible to remove it from the compiler? How does it work? Does it >look at the code, or is anything called login.c susceptible? Why has this >not been removed in the open-source code? How can I check to see if this >backdoor exists? > >TIA, >Carsten I believe Dean is mistaken and is actually referring to Ken Thompson's theoretical attack. The point is you can't see if the backdoor exists. Unless you have personally recreated the history of modern computing from first priciples in your basement or place of work, you may be 0wn3d and not know it, in theory. In practice, you can be pretty sure you're okay by cross-compiling your entire system using GCC compiled from a vendor-supplied compiler. You can be 99.99999% sure you're okay if you cross-compile GCC 3.3 and an entire NetBSD sytem for a 68k Mac using GCC 1.0 (or the ealiest veriosn that will cross-compile for m68k NetBSD) on IRIX MIPS (compiled using SGI's CC) and then cross-compile your entire Linux distro for x86 from NetBSD on that 68k box. That amount of change across architectures, generations, and vendors makes implementing a virus that would survive that transition nearly impossible. If you need more assurances than that, you better reverse-engineer your HD firmware to look for viruses that might insert themselves in your kernel at boot time. There is no escaping the need to trust trust. In theory a PDP-11 CPU microcode virus may have inserted itself in a hardware design for a memory controller on a machine that was used to write the hard drive firmware for the HD on the machine that was used to design the memory controller for the original IBM PC and it may have hitched a ride along the deign process all the way until it ended up in the hardware and microcode in your Athlon so that it improperly implements the jne operation when it is followed by a series of operations characteristic of checking a particular password. Are there any references to Kernigan's compiler hacks? I believe Dean is actually referring to Ken Thompson's famous paper "Reflections on Trusting Trust". Ken Thompson only theorized such an attack and I am not aware of anyone that ever implemented a proof-of-concept for the attack. The whole point of the paper is that at a certain point, you're placing trust in the history of all of the tools and all of the hardware used to make your tools and your hardware. If you need absolute trust in your system, you'll need to make your own simple computer from discrete transistors, resistors, etc. and design a CAD system for it on paper in its machine code. You then load the CAD program into the machine manually byte by byte using dip switches or else you make your own punch card system to load the computer. You use the CAD system do design an entire computer and create the fab masks for all of the components using your trusted system, then fab the components (including RAM and any persistant storage you were going to use) yourself in your own fab. You would need to make your CPU immune to microcode viruses. You would then use your trusted CAD machine to write the bootstrapping code for your fabbed machine and an assembler for the fabbed machine. You'd then be able to finally boot a trusted machine with reasonable speed and have a trusted assembler. You'd use this to build a trusted C compiler. Then you'd review every line of code in the entire GNU/Linux system (well, at a bare minimum the kernel, the shell, and the initial process) you were going to compile. You gain confidence in your system by verifying the hardware and software history. The further back in time you verify things, the harder it is for an attacker to mount an attack. Unfortunately, for absolute trust you would in fact need to make your own whicker transistors and other components in your discrete component machine, otherwise there could be a microchip hidden in the transistor, vacuum tube, or relays you used that could talk to each other via subliminal channels and figure out when they were doing computations for a CPU or memory controller and introduce a hardware virus. That level of paranoia is rediculous, even for the NSA. If you're up against something that survives cross-compiling across 10 generations, vendors, and architectures, you should really give up because the cost of victory will be too high. -Karl -------- Karl Alexander Magdsick <karlm@mit.edu> "The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands at times of challenge and controversy." -- Martin Luther King Jr. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-23 19:34 ` Linuxfromscratch.org karlm @ 2003-07-23 22:08 ` Dean Anderson 2003-07-24 14:06 ` Linuxfromscratch.org Dale Amon 2003-07-24 14:16 ` Linuxfromscratch.org Dale Amon 2003-07-24 17:40 ` Linuxfromscratch.org Colin Walters 2003-07-27 15:19 ` Linuxfromscratch.org Tom 2 siblings, 2 replies; 24+ messages in thread From: Dean Anderson @ 2003-07-23 22:08 UTC (permalink / raw) To: karlm; +Cc: Carsten P. Gehrke, Russell Coker, Charlie Watts, selinux It could very well have been Ken Thompson who did or thought up the original hack. I never saw a paper (at least I don't recall seeing a paper.) I believe I heard it verbally either from Peter Salus or perhaps at a Usenix many years ago. Peter Salus was employed at the OSF when I was there, and has since written a book on the History of Unix, and told many regalling stories about Unix. But I learned of this at least 12+ years ago, so memory fades as to the exact details. But the details are of little consequence. In principle, the same hack could be done again, perhaps at a Linux distribution vendor. Karl makes a very good point that complete trust is hard to ever have. However, Redhat and other Linux/FreeBSD/NetBSD/etc distibutions are not exactly the NSA in terms of computer security, and security varies quite a lot. However, I would like to point out that if the hack inserts source code at a certain point in a certain file, then cross compilation will not remove the hack, no matter how many odd architectures one goes through. I think Lukasz Luzar's procedure is probably the more reasonable for most purposes. BTW, I've read rumors (Bamford's Body of Secrets) that the NSA does make it own chips. Maybe for this reason....;-) --Dean On Wed, 23 Jul 2003 karlm@MIT.EDU wrote: > > >At 13:49 22-07-03, Dean Anderson wrote: > >>if you are looking for integrity, Linuxfromscratch is just the start. > >> > >>You have to come up with a way to exclude Kerningan-style compiler hacks, > >>and similar OS hacks from being inserted into the "clean" source build. > >> > >>Kernigan, as some will remember, early in Unix days (70s), altered the > >>compiler to include a backdoor in login when it compiled login.c, and > >>altered the compiler to insert the backdoor-inserter whenever it compiled > >>itself. So even if you recompiled Unix from scratch from clean source, > >>you still had a backdoor. I think even if you retargeted the compiler, it > >>still inserted to the apprpropriate backdoor-inserter. A similar hack can > >>be done at the OS level. > >> > >> --Dean > > > >Is this true of the GNU C compiler suite as well? And if so, would it not > >be possible to remove it from the compiler? How does it work? Does it > >look at the code, or is anything called login.c susceptible? Why has this > >not been removed in the open-source code? How can I check to see if this > >backdoor exists? > > > >TIA, > >Carsten > > I believe Dean is mistaken and is actually referring to Ken Thompson's > theoretical attack. The point is you can't see if the backdoor > exists. Unless you have personally recreated the history of modern > computing from first priciples in your basement or place of work, you > may be 0wn3d and not know it, in theory. > > In practice, you can be pretty sure you're okay by cross-compiling > your entire system using GCC compiled from a vendor-supplied compiler. > You can be 99.99999% sure you're okay if you cross-compile GCC 3.3 and > an entire NetBSD sytem for a 68k Mac using GCC 1.0 (or the ealiest > veriosn that will cross-compile for m68k NetBSD) on IRIX MIPS > (compiled using SGI's CC) and then cross-compile your entire Linux > distro for x86 from NetBSD on that 68k box. That amount of change > across architectures, generations, and vendors makes implementing a > virus that would survive that transition nearly impossible. If you > need more assurances than that, you better reverse-engineer your HD > firmware to look for viruses that might insert themselves in your > kernel at boot time. > > There is no escaping the need to trust trust. In theory a PDP-11 CPU > microcode virus may have inserted itself in a hardware design for a > memory controller on a machine that was used to write the hard drive > firmware for the HD on the machine that was used to design the memory > controller for the original IBM PC and it may have hitched a ride > along the deign process all the way until it ended up in the hardware > and microcode in your Athlon so that it improperly implements the jne > operation when it is followed by a series of operations characteristic > of checking a particular password. > > Are there any references to Kernigan's compiler hacks? I believe Dean > is actually referring to Ken Thompson's famous paper "Reflections on > Trusting Trust". Ken Thompson only theorized such an attack and I am > not aware of anyone that ever implemented a proof-of-concept for the > attack. > > The whole point of the paper is that at a certain point, you're > placing trust in the history of all of the tools and all of the > hardware used to make your tools and your hardware. If you need > absolute trust in your system, you'll need to make your own simple > computer from discrete transistors, resistors, etc. and design a CAD > system for it on paper in its machine code. You then load the CAD > program into the machine manually byte by byte using dip switches or > else you make your own punch card system to load the computer. You > use the CAD system do design an entire computer and create the fab > masks for all of the components using your trusted system, then fab > the components (including RAM and any persistant storage you were > going to use) yourself in your own fab. You would need to make your > CPU immune to microcode viruses. You would then use your trusted CAD > machine to write the bootstrapping code for your fabbed machine and an > assembler for the fabbed machine. You'd then be able to finally boot > a trusted machine with reasonable speed and have a trusted assembler. > You'd use this to build a trusted C compiler. Then you'd review every > line of code in the entire GNU/Linux system (well, at a bare minimum the > kernel, the shell, and the initial process) you were going to compile. > > You gain confidence in your system by verifying the hardware and > software history. The further back in time you verify things, the > harder it is for an attacker to mount an attack. Unfortunately, for > absolute trust you would in fact need to make your own whicker > transistors and other components in your discrete component machine, > otherwise there could be a microchip hidden in the transistor, vacuum > tube, or relays you used that could talk to each other via subliminal > channels and figure out when they were doing computations for a CPU or > memory controller and introduce a hardware virus. That level of > paranoia is rediculous, even for the NSA. If you're up against > something that survives cross-compiling across 10 generations, vendors, and > architectures, you should really give up because the cost of victory will > be too high. > > > -Karl > > -------- > Karl Alexander Magdsick <karlm@mit.edu> > > "The ultimate measure of a man is not where he stands in moments of > comfort and convenience, but where he stands at times of challenge > and controversy." -- Martin Luther King Jr. > > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-23 22:08 ` Linuxfromscratch.org Dean Anderson @ 2003-07-24 14:06 ` Dale Amon 2003-07-24 14:16 ` Linuxfromscratch.org Dale Amon 1 sibling, 0 replies; 24+ messages in thread From: Dale Amon @ 2003-07-24 14:06 UTC (permalink / raw) To: Dean Anderson Cc: karlm, Carsten P. Gehrke, Russell Coker, Charlie Watts, selinux On Wed, Jul 23, 2003 at 06:08:33PM -0400, Dean Anderson wrote: > It could very well have been Ken Thompson who did or thought up the > original hack. I never saw a paper (at least I don't recall seeing a > paper.) I believe I heard it verbally either from Peter Salus or perhaps I read the paper long ago also and I'd have sworn I had it in my files but I drew a blank on my short search. I thought it was Kernighan's paper but I could well be wrong. I'm pretty sure it did show some "sample" code. It certainly described the whole process. I think it was presented at a Usenix. -- ------------------------------------------------------ IN MY NAME: Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org ------------------------------------------------------ -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-23 22:08 ` Linuxfromscratch.org Dean Anderson 2003-07-24 14:06 ` Linuxfromscratch.org Dale Amon @ 2003-07-24 14:16 ` Dale Amon 2003-07-24 14:18 ` Linuxfromscratch.org Dale Amon 1 sibling, 1 reply; 24+ messages in thread From: Dale Amon @ 2003-07-24 14:16 UTC (permalink / raw) To: Dean Anderson Cc: karlm, Carsten P. Gehrke, Russell Coker, Charlie Watts, selinux On Wed, Jul 23, 2003 at 06:08:33PM -0400, Dean Anderson wrote: > It could very well have been Ken Thompson who did or thought up the > original hack. I never saw a paper (at least I don't recall seeing a > paper.) I believe I heard it verbally either from Peter Salus or perhaps > at a Usenix many years ago. Peter Salus was employed at the OSF when I was My memory says Kernighan at a Usenix, but I read it a long time ago. I thought I had a copy of the paper in my files but a quick search came up blank. -- ------------------------------------------------------ IN MY NAME: Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org ------------------------------------------------------ -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-24 14:16 ` Linuxfromscratch.org Dale Amon @ 2003-07-24 14:18 ` Dale Amon 0 siblings, 0 replies; 24+ messages in thread From: Dale Amon @ 2003-07-24 14:18 UTC (permalink / raw) To: Dean Anderson Cc: karlm, Carsten P. Gehrke, Russell Coker, Charlie Watts, selinux Oopps, sorry about the two messages. I thought I'd hit the wrong key and lost the first one instead of sending it. I need more coffee :-) -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-23 19:34 ` Linuxfromscratch.org karlm 2003-07-23 22:08 ` Linuxfromscratch.org Dean Anderson @ 2003-07-24 17:40 ` Colin Walters 2003-07-24 18:52 ` Linuxfromscratch.org Dean Anderson 2003-07-24 19:42 ` Linuxfromscratch.org Russell Coker 2003-07-27 15:19 ` Linuxfromscratch.org Tom 2 siblings, 2 replies; 24+ messages in thread From: Colin Walters @ 2003-07-24 17:40 UTC (permalink / raw) To: selinux On Wed, 2003-07-23 at 15:34, karlm@mit.edu wrote: > I believe Dean is mistaken and is actually referring to Ken Thompson's > theoretical attack. The point is you can't see if the backdoor > exists. Unless you have personally recreated the history of modern > computing from first priciples in your basement or place of work, you > may be 0wn3d and not know it, in theory. The thing is though that to do any kind of "useful" damage (e.g. send passwords back to the author), at some point the trojan is going to have to connect to the network. And if it does that, chances are some careful network administrator somewhere is going to notice some strange connections, eventually. I mean, when your file server starts making HTTP POST requests or whatever, you'd get very suspicious. It seems much harder to believe this trojan would have been able to compromise all the network traffic sniffers out there. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-24 17:40 ` Linuxfromscratch.org Colin Walters @ 2003-07-24 18:52 ` Dean Anderson 2003-07-27 15:28 ` Linuxfromscratch.org Tom 2003-07-24 19:42 ` Linuxfromscratch.org Russell Coker 1 sibling, 1 reply; 24+ messages in thread From: Dean Anderson @ 2003-07-24 18:52 UTC (permalink / raw) To: Colin Walters; +Cc: selinux Someone sent this to me privately: --------- It was Ken. Google knows all. See http://www.wbglinks.net/pages/reads/hacksexplained/thompson.html --------- Regarding the "useful" damage, if the trojan accepts another pre-defined password, then you don't need an outbound connection to tell you the passwords. However, there has been some recent discussion of using charactistics of packets to trigger finite state machines. One example I read recently of (don't remember the source), was using a FSM in a firewall to remotely open holes for authorized users in a manner that would be hard to detect with a sniffer. Sending a certain sequence could communicate the port numbers and IP addresses to open. --Dean On 24 Jul 2003, Colin Walters wrote: > On Wed, 2003-07-23 at 15:34, karlm@mit.edu wrote: > > > I believe Dean is mistaken and is actually referring to Ken Thompson's > > theoretical attack. The point is you can't see if the backdoor > > exists. Unless you have personally recreated the history of modern > > computing from first priciples in your basement or place of work, you > > may be 0wn3d and not know it, in theory. > > The thing is though that to do any kind of "useful" damage (e.g. send > passwords back to the author), at some point the trojan is going to have > to connect to the network. And if it does that, chances are some > careful network administrator somewhere is going to notice some strange > connections, eventually. I mean, when your file server starts making > HTTP POST requests or whatever, you'd get very suspicious. > > It seems much harder to believe this trojan would have been able to > compromise all the network traffic sniffers out there. > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-24 18:52 ` Linuxfromscratch.org Dean Anderson @ 2003-07-27 15:28 ` Tom 2003-07-27 20:13 ` Linuxfromscratch.org Colin Walters 0 siblings, 1 reply; 24+ messages in thread From: Tom @ 2003-07-27 15:28 UTC (permalink / raw) To: Dean Anderson; +Cc: Colin Walters, selinux On Thu, Jul 24, 2003 at 02:52:02PM -0400, Dean Anderson wrote: > Regarding the "useful" damage, if the trojan accepts another pre-defined > password, then you don't need an outbound connection to tell you the > passwords. However, there has been some recent discussion of using > charactistics of packets to trigger finite state machines. One example I > read recently of (don't remember the source), was using a FSM in a > firewall to remotely open holes for authorized users in a manner that > would be hard to detect with a sniffer. Sending a certain sequence could > communicate the port numbers and IP addresses to open. Actually, the current state of the art is embedding arbitrary commands in regular traffic. Opening ports is just one possibility, and usually unnecessary if you have what is essentially a remote shell. I've seen working implementations of that. They use encryption and changing start/end patterns. You can embed your commands in HTTP requests, or spam mail, or hidden in the IP flags of a ping series. Good luck with the IDS. Which goes to show that you can't have security unless the system itself is secure. No amount of firewalling, filtering or IDS will protect a weak system. That's why we need SELinux. (how's that for getting back on-topic? :) ) -- http://web.lemuria.org/pubkey.html pub 1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org> Key fingerprint = C731 64D1 4BCF 4C20 48A4 29B2 BF01 9FA1 2D7A 04F5 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-27 15:28 ` Linuxfromscratch.org Tom @ 2003-07-27 20:13 ` Colin Walters 2003-07-28 17:17 ` Linuxfromscratch.org Tom 0 siblings, 1 reply; 24+ messages in thread From: Colin Walters @ 2003-07-27 20:13 UTC (permalink / raw) To: selinux On Sun, 2003-07-27 at 11:28, Tom wrote: > On Thu, Jul 24, 2003 at 02:52:02PM -0400, Dean Anderson wrote: > > Regarding the "useful" damage, if the trojan accepts another pre-defined > > password, then you don't need an outbound connection to tell you the > > passwords. However, there has been some recent discussion of using > > charactistics of packets to trigger finite state machines. One example I > > read recently of (don't remember the source), was using a FSM in a > > firewall to remotely open holes for authorized users in a manner that > > would be hard to detect with a sniffer. Sending a certain sequence could > > communicate the port numbers and IP addresses to open. > > Actually, the current state of the art is embedding arbitrary commands > in regular traffic. Opening ports is just one possibility, and usually > unnecessary if you have what is essentially a remote shell. > I've seen working implementations of that. They use encryption and changing > start/end patterns. You can embed your commands in HTTP requests, or > spam mail, or hidden in the IP flags of a ping series. Good luck with > the IDS. That is clever, but it seems to me you'd still have to take into account the machine's usage. Again, none of what you listed above should be going to a file server, for example. And most of it shouldn't be going to a development workstation. So it doesn't seem too unlikely that some machine learning based IDS, somewhere, will eventually pick up on it. Once that happens in multiple places, people will get suspicious. I guess all I'm saying is that the chances of a trojan going undetected for a long period of time approaches nil. > Which goes to show that you can't have security unless the system > itself is secure. No amount of firewalling, filtering or IDS will > protect a weak system. That's why we need SELinux. (how's that for > getting back on-topic? :) ) Good work :) -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-27 20:13 ` Linuxfromscratch.org Colin Walters @ 2003-07-28 17:17 ` Tom 0 siblings, 0 replies; 24+ messages in thread From: Tom @ 2003-07-28 17:17 UTC (permalink / raw) To: Colin Walters; +Cc: selinux On Sun, Jul 27, 2003 at 04:13:04PM -0400, Colin Walters wrote: > That is clever, but it seems to me you'd still have to take into account > the machine's usage. Again, none of what you listed above should be > going to a file server, for example. Those were just examples. You can put your stuff into ANY traffic. If the machine has any outside connections whatsoever, and be they DNS requests, you have a channel you can use. > to a development workstation. So it doesn't seem too unlikely that some > machine learning based IDS, somewhere, will eventually pick up on it. > Once that happens in multiple places, people will get suspicious. > I guess all I'm saying is that the chances of a trojan going undetected > for a long period of time approaches nil. True, but "long period of time" is relative. All you need is enough time to accomplish your goal. That may be months or seconds, depending on what the goal is. Again, we see why SELinux is what it is - all the race conditions and other timing-based exploits show that "we'll catch them quickly" isn't enough. Catching them works if you talk about theft or something else where you can still undo the damage. It doesn't work for murder or rape. Same in computer security: If you have something where the damage likely can't be undone, monitoring isn't the correct approach because it acts too late. -- http://web.lemuria.org/pubkey.html pub 1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org> Key fingerprint = C731 64D1 4BCF 4C20 48A4 29B2 BF01 9FA1 2D7A 04F5 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-24 17:40 ` Linuxfromscratch.org Colin Walters 2003-07-24 18:52 ` Linuxfromscratch.org Dean Anderson @ 2003-07-24 19:42 ` Russell Coker 1 sibling, 0 replies; 24+ messages in thread From: Russell Coker @ 2003-07-24 19:42 UTC (permalink / raw) To: Colin Walters, selinux On Thu, 24 Jul 2003 13:40, Colin Walters wrote: > The thing is though that to do any kind of "useful" damage (e.g. send > passwords back to the author), at some point the trojan is going to have The theoretical trojan in question had one aim, to give a certain person root access without log entries. You are correct that some other things could be caught by network analysis, but that is more difficult than it seems. Also in SE Linux the login process is not permitted network access in a default config which helps. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-23 19:34 ` Linuxfromscratch.org karlm 2003-07-23 22:08 ` Linuxfromscratch.org Dean Anderson 2003-07-24 17:40 ` Linuxfromscratch.org Colin Walters @ 2003-07-27 15:19 ` Tom 2 siblings, 0 replies; 24+ messages in thread From: Tom @ 2003-07-27 15:19 UTC (permalink / raw) To: selinux On Wed, Jul 23, 2003 at 03:34:44PM -0400, karlm@mit.edu wrote: > tube, or relays you used that could talk to each other via subliminal > channels and figure out when they were doing computations for a CPU or > memory controller and introduce a hardware virus. That level of > paranoia is rediculous, even for the NSA. Actually, I believe the common critera EAL 7 asks for a good part of it. There's a reason EAL 4 is the highest level used in the commercial world. -- http://web.lemuria.org/pubkey.html pub 1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org> Key fingerprint = C731 64D1 4BCF 4C20 48A4 29B2 BF01 9FA1 2D7A 04F5 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-23 15:09 ` Linuxfromscratch.org Carsten P. Gehrke 2003-07-23 15:44 ` Linuxfromscratch.org Russell Coker 2003-07-23 19:34 ` Linuxfromscratch.org karlm @ 2003-07-23 20:26 ` Lukasz Luzar 2003-07-24 0:29 ` Linuxfromscratch.org Dale Amon 2 siblings, 1 reply; 24+ messages in thread From: Lukasz Luzar @ 2003-07-23 20:26 UTC (permalink / raw) To: Carsten P. Gehrke; +Cc: selinux Hello, > Is this true of the GNU C compiler suite as well? And if so, would it not > be possible to remove it from the compiler? How does it work? Does it > look at the code, or is anything called login.c susceptible? Why has this > not been removed in the open-source code? How can I check to see if this > backdoor exists? I suppose there's a "simple" way to avoid backdoors in gcc-like compilers ;-) Assuming the BIOS is not backdoored, the simplified steps are: 1). Perform a security audit of a simplest public-available C compiler [1] written in ANSI C 2). Convert the C compiler's _source_code_ (written in ANSI C) into x86 assembler _source_code_ by yourself, replacing all OS-depended interrupts etc. 3). Write a simplest (low-efficient, but trusted) assembler compiler (~a x86 assembler source code converter into x86 machine-code ;-) preferably targeted on a less popular processor (even a 8051...) 4). Compile the audited C compiler, converted into x86 assembler source code, by using the above tool, so the final trusted compiler to be OS-independent and floopy-bootable and has a simple built-in shell etc. ;-) 5). Do some tricks to copy the trusted C compiler on a floppy and make it bootable 6). Launch the trusted & independent compiler from the bootable floppy 7). Compile the compiler [1], a shell, libs and all tools needed to compile Linux kernel by using your own trusted compiler booted from the floppy 8). Compile a simplest Linux kernel using these tools 9). Put the kernel on a prepared bootable partition 10). Copy the compiled tools on the partition 11). Boot the Linux from this partition 12). Recompile all required packages needed for your distribution according to LFS documentation. Cheers, -- Lukasz Luzar http://Developers.of.PL/ Crede quod habes, et habes [[ http://galeria.luzar.pl/ ]] /* paran01a 1s a v1rtu3 */ -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-23 20:26 ` Linuxfromscratch.org Lukasz Luzar @ 2003-07-24 0:29 ` Dale Amon 2003-07-24 6:39 ` Linuxfromscratch.org Brian May 0 siblings, 1 reply; 24+ messages in thread From: Dale Amon @ 2003-07-24 0:29 UTC (permalink / raw) To: Lukasz Luzar; +Cc: Carsten P. Gehrke, selinux On Wed, Jul 23, 2003 at 10:26:42PM +0200, Lukasz Luzar wrote: > Hello, > > > Is this true of the GNU C compiler suite as well? And if so, would it not > > be possible to remove it from the compiler? How does it work? Does it > > look at the code, or is anything called login.c susceptible? Why has this > > not been removed in the open-source code? How can I check to see if this > > backdoor exists? Of course you could always create a file like this: login.c main () { printf ("Hello World\n"); } and the hand decompile the binary to see if there is anything unexpected present. -- ------------------------------------------------------ IN MY NAME: Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org ------------------------------------------------------ -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-24 0:29 ` Linuxfromscratch.org Dale Amon @ 2003-07-24 6:39 ` Brian May 2003-07-24 12:32 ` Linuxfromscratch.org Dale Amon 0 siblings, 1 reply; 24+ messages in thread From: Brian May @ 2003-07-24 6:39 UTC (permalink / raw) To: Dale Amon; +Cc: Lukasz Luzar, Carsten P. Gehrke, selinux On Thu, Jul 24, 2003 at 01:29:49AM +0100, Dale Amon wrote: > On Wed, Jul 23, 2003 at 10:26:42PM +0200, Lukasz Luzar wrote: > > > Is this true of the GNU C compiler suite as well? And if so, would it not > > > be possible to remove it from the compiler? How does it work? Does it > > > look at the code, or is anything called login.c susceptible? Why has this > > > not been removed in the open-source code? How can I check to see if this > > > backdoor exists? > > Of course you could always create a file like this: > > login.c > main () { printf ("Hello World\n"); } > > and the hand decompile the binary to see if there > is anything unexpected present. Does this proove anything though? A trojon horse in the compiler could be clever enough not to insert any back doors on such simple code... -- Brian May <bam@snoopy.apana.org.au> -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-24 6:39 ` Linuxfromscratch.org Brian May @ 2003-07-24 12:32 ` Dale Amon 0 siblings, 0 replies; 24+ messages in thread From: Dale Amon @ 2003-07-24 12:32 UTC (permalink / raw) To: Dale Amon, Lukasz Luzar, Carsten P. Gehrke, selinux On Thu, Jul 24, 2003 at 04:39:49PM +1000, Brian May wrote: > > login.c > > main () { printf ("Hello World\n"); } > > > > and the hand decompile the binary to see if there > > is anything unexpected present. > > Does this proove anything though? > > A trojon horse in the compiler could be clever enough not to insert > any back doors on such simple code... There are some safe assumptions we can make: * The trojan is not arbitrarily complex as it must have compiled into the size of the early gcc. * It is not arbitrarily specific or else it would only have worked on the earliest login.c and thus we can escape it simply by changing the login.c code. So it is either simple minded or there are certain features in a login.c that all C programmers will recreate even if starting from a blank emacs windows and no knowledge of the original login.c other than a minimal functional requirement doc. So get 100 junior programmers to write one hundred login.c's from scratch and see what they have in common. But I'll short circuit it. If I were coding this in C back in 1977, I'd have done a string compare on Username: and Password:. -- ------------------------------------------------------ IN MY NAME: Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org ------------------------------------------------------ -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Linuxfromscratch.org 2003-07-22 20:06 ` Linuxfromscratch.org Russell Coker 2003-07-22 20:49 ` Linuxfromscratch.org Dean Anderson @ 2003-07-23 1:17 ` Carsten P. Gehrke 1 sibling, 0 replies; 24+ messages in thread From: Carsten P. Gehrke @ 2003-07-23 1:17 UTC (permalink / raw) To: Russell Coker, Charlie Watts, selinux At 13:06 22-07-03, Russell Coker wrote: >On Mon, 21 Jul 2003 21:42, Charlie Watts wrote: > > I want to make a linux system from scratch. I have never compiled my > > own kernel, but I was wondering if i could start with the SE Linux > > kernel. I am using the instructions from linuxfromscratch.org to make > > the system on my laptop, which is running Mandrake 9, on a i686, 512Mb > > ram, and a 1.13 GHz P IV. Ext3 file system. Any advice would be great. > >I recommend that you compile your own kernel without SE Linux first, and then >try using SE Linux after you have had some practise at building your own >kernel. Otherwise if you have a problem you won't know whether it's SE Linux >related or just a general kernel build issue. I plan to use SE Linux with an LFS system as well. I have already performed on LFS installation, and have built an SEL kernel on a Red Hat machine. Am I correct in assuming that the major problem will be getting the access controls and security policies right? I think LFS differs a bit from Red Hat as far as certain users and certain files are concerned, and then each LFS system is different because each administrator "rolls his own". My application for SEL would be as the OS for my firewall. -- Carsten Gehrke LFS No.: 190 using Linux since kernel 0.98 carsten@gehrke.org -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2003-07-28 17:35 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-07-22 1:42 Linuxfromscratch.org Charlie Watts 2003-07-22 20:06 ` Linuxfromscratch.org Russell Coker 2003-07-22 20:49 ` Linuxfromscratch.org Dean Anderson 2003-07-23 15:09 ` Linuxfromscratch.org Carsten P. Gehrke 2003-07-23 15:44 ` Linuxfromscratch.org Russell Coker 2003-07-23 20:01 ` Linuxfromscratch.org Dale Amon 2003-07-23 21:24 ` Linuxfromscratch.org Dean Anderson 2003-07-23 19:34 ` Linuxfromscratch.org karlm 2003-07-23 22:08 ` Linuxfromscratch.org Dean Anderson 2003-07-24 14:06 ` Linuxfromscratch.org Dale Amon 2003-07-24 14:16 ` Linuxfromscratch.org Dale Amon 2003-07-24 14:18 ` Linuxfromscratch.org Dale Amon 2003-07-24 17:40 ` Linuxfromscratch.org Colin Walters 2003-07-24 18:52 ` Linuxfromscratch.org Dean Anderson 2003-07-27 15:28 ` Linuxfromscratch.org Tom 2003-07-27 20:13 ` Linuxfromscratch.org Colin Walters 2003-07-28 17:17 ` Linuxfromscratch.org Tom 2003-07-24 19:42 ` Linuxfromscratch.org Russell Coker 2003-07-27 15:19 ` Linuxfromscratch.org Tom 2003-07-23 20:26 ` Linuxfromscratch.org Lukasz Luzar 2003-07-24 0:29 ` Linuxfromscratch.org Dale Amon 2003-07-24 6:39 ` Linuxfromscratch.org Brian May 2003-07-24 12:32 ` Linuxfromscratch.org Dale Amon 2003-07-23 1:17 ` Linuxfromscratch.org Carsten P. Gehrke
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.