Re: Anaconda patches

On Wed, 2003-12-03 at 16:50, Dean Anderson wrote:
> Patch 1 fixes a problem with booting rescue mode on a serial console and 
> also includes adding -64 and -32 to image names. Since the distribution 
> does this, the anaconda used in creating the distribution images must be 
> different than the one on the 1.0 distribution...

No, I just did a lot of it by hand/scripted. Good catch though.

> Patch 2 allows the use of an FTP site for kickstart.  No rocket science. I 
> notice that anaconda is running out of flag space. Only 5 bits left...

Can you check Fedora's anaconda to see if these patches can be made to
apply upstream? At this point, unless there is significant demand, I
don't plan on respinning Build 1.0.

> While I'm on the subject, one thing I am considering is a adding another
> 'gui' framework that doesn't use the snack text menu system.  I like the
> text gui, and I also like the Gnome gui, all in the right contexts.  What
> I seem to require yet is an interface that can be supervised by expect.  
> Is anyone else interested in this?

I'm not sure how useful this would be... doesn't this do the same thing
as kickstart? If its automated, it doesn't really matter what gui
interface it uses... but you might want to ask Jeremy Katz what he
thinks.

> One use of fully automated, expect supervised installation is the periodic
> netbooting of a virus/worm/crack checker, which (from a netbooted clean
> kernel), checks the real system for inappropriate file changes. It is now
> clear to me that a running system can't be trusted to check itself, given
> the possibility of a kernel compromise**.  The netboot image, after
> finding a problem, then just has to notify something/someone, perhaps
> backup non-OS files (using RPM database as a guide), and probably modified
> OS files, and an then perhaps an automated reinstall can then take place.  
> No fuss, no travel, and back up in minimum time.

Interesting. However, this is likely something that could be scripted
easily via kickstart on the remote host.

> **I'm in possession of a kernel module rootkit that I can't find when its
> successfully installed.  When running, it is undetectable.  The only way
> to detect it is to boot something else. Only then will you be able to see
> the modified files. I only got it (source) because I happened to catch it
> during download from a cracked server at ISC.org in October, 2001, and I
> was able to kill its installation.  I notified Mark Andrews about this
> back then.  His response was that the IP address I gave was a Tru64 box,
> and a Tru64 machine can't be used to crack an intel linux box.  I tried to
> explain that this isn't the case.  So, I've stopped using ISC software.

Red Hat would undoubtedly like to get a copy of this, if its not a
publicly known rootkit.

Any chance of sharing that? I can give you a security contact at Red Hat
if you're interested.

Thanks for the patches!

~spot
---
Tom "spot" Callaway <tcallawa(a)redhat*com> LCA, RHCE 
Red Hat Sales Engineer || Aurora SPARC Linux Project Leader

"The author's mathematical treatment of the conception of purpose is
novel and highly ingenious, but heretical and, so far as the present
social order is concerned, dangerous and potentially subversive. Not to
be published." -- Aldous Huxley's "Brave New World"

_______________________________________________
Aurora-sparc-devel mailing list
[email protected]
http://lists.auroralinux.org/mailman/listinfo/aurora-sparc-devel
Aurora FAQ: http://www.ecs.soton.ac.uk/~mas01r/aurorafaq.html