Linuxfromscratch.org

Linuxfromscratch.org

[Charlie Watts]

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.

Re: Linuxfromscratch.org

[Russell Coker]

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.

Re: Linuxfromscratch.org

[Dean Anderson]

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.

Re: Linuxfromscratch.org

[Carsten P. Gehrke]

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.

Re: Linuxfromscratch.org

[Carsten P. Gehrke]

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.

Re: Linuxfromscratch.org

[Russell Coker]

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.

Re: Linuxfromscratch.org

[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.

Re: Linuxfromscratch.org

[Dale Amon]

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.

Re: Linuxfromscratch.org

[Lukasz Luzar]

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.

Re: Linuxfromscratch.org

[Dean Anderson]

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.

Re: Linuxfromscratch.org

[Dean Anderson]

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.

Re: Linuxfromscratch.org

[Dale Amon]

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.

Re: Linuxfromscratch.org

[Brian May]

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.

Re: Linuxfromscratch.org

[Dale Amon]

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.

Re: Linuxfromscratch.org

[Dale Amon]

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.

Re: Linuxfromscratch.org

[Dale Amon]

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.

Re: Linuxfromscratch.org

[Dale Amon]

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.

Re: Linuxfromscratch.org

[Colin Walters]

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.

Re: Linuxfromscratch.org

[Dean Anderson]

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.

Re: Linuxfromscratch.org

[Russell Coker]

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.

Re: Linuxfromscratch.org

[Tom]

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.

Re: Linuxfromscratch.org

[Tom]

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.

Re: Linuxfromscratch.org

[Colin Walters]

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.

Re: Linuxfromscratch.org

[Tom]

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.