Re: SEUL: Common SEUL/e-linux tools needed

[William T Wilson <fluffy@benatar.dunadan.com>]

On Wed, 7 Jan 1998, Loren S Osborn wrote:

> > > 	Linux Emulator:

No.  In a word, no.  This is not something that we are going to even have
approximately done this year or probably even next year.  I'd like to do a
full-blown x86 emulator eventually for a whole other reason, because if we
had one we could run Win95 in it and put portability to rest.  However,
there's rather a lot to a project like this.  The two issues that crop up
are how to emulate devices, and how to make it run at a reasonable speed.
There's very little point in running Linux in one other than to show that
it could in fact be done.  :)

> Well, for one thing, this is supposed to help catch non-well behaved
> programs. 

chroot is still the best solution.  It's difficult for even an experienced
hacker to get out of a chroot().  basically, a chroot() seals off the
entire systems, except that processes, sockets, and devices are not
"broken" across the chroot.  That is, a program can use a /dev/hda device
to access files on the directories outside the chroot().  Of course, the
device file has to exist for this to happen.  A root program can create
one, but... And a program can still connect to an X-server running on the
same machine, or send signals to programs running outside the chroot. 
It's highly unlikely that a program would actually manage to break this
and do any actual damage accidentally. 

> Also, I would like to be able to check the program on all five popular
> Linux hardware platforms (ix86, m680x0, PPC, Alpha, Sparc/Ultra )
> through emulation.  Specifically, the ix86 cannot fully emulate

Whee!  Now instead of one difficult emulator to write we have five.  SOME
of the work emulating x86 and Alpha (which have very similar system
architecture, despite their very different CPU's) could be shared.
Everything else has to be done from scratch.  Let's not even think of it.
:)  My guess is that we won't fool with any platform other than x86
anyway.  Anyone that has an Alpha or a Sparc is going to be smart enough
to run plain old RedHat.

> to run as root... (Not to mention that a full emulation of the ix86
> might give the Wine project a boost.) 

No, but as I mentioned, we could run Windows in it and be done with
compatilibity problems altogether.  If M$ can write it, we can run it.
Sounds neat, but you really have no idea the unimaginable amount of work
involved.  It would be about the scale of DOSEmu and about half the kernel
too.

> 	1) I have found that the 'rpm' program from RedHat seems to keep
> 		records poorly, and is easy to confuse.

All package managers get confused easily. It's just the nature of the
beast.  debian, slackware, and Windows all have easily confused package
systems too.

> 	2) I dislike that most RPM that are availible don't contain
> 		source-code, and the ones that do don't compile
> 		automatically in the background. 

Not a problem.  Almost every RPM available has a corresponding SRPM, you
just don't see them as often.  And building them is just plain simple.  We
can script it, for those rare cases where we need to fool with source at
all (hopefully not very often).

> 	3) I think that if we want to have plug-in modules for this
> 		configuration tool included with *ALL* packages, then
> 		we need to have a new format that gaugentees that such
> 		a file does *INDEED* come with each package.

What?  dpkg and RPM both have perfectly adequate verification systems.  If
we leave the configuration file out of a package, that's our brain-dead
maneuver.  Let's just not screw up like that (of course, RedHat left the
executable out of the Kaffe package in 5.0... :) )

> 	4) The PGP key, and the integrity checking will provide a moderate

RPM implements MD5 checking, already, which will protect against corrupted
files.  Developer hostility is just not something we should worry about.
We can't prevent users from installing bogus packages, with a little luck,
that shouldn't be a problem.  I've never heard of it happening to any
other distribution, why would it hit us?

> Most likely *WE* will have to originally adapt each .tgz file to each
> package

We'll end up doing most of this already.  That's what distribution
maintainers do, they take tarballs and make them into their packages.