Bastille Linux: Next Steps discussion notes

These are all of the suggestions people made during our Bastille Linux: Next Steps discussion. They do not necessarily represent the consensus of the Bastille Linux development team or a commitment to implement these features; they were only suggestions, and will be evaluated individually on their merits as time goes on. They are provided on the web as a service to those who missed participating in the discussion.

Platform support:
	Interest in Sparc and Alpha
		If anyone gives us hardware, we can try it :-)

Distribution support:
	restructure filesystem via fsstd?
	Use locate database to find executables / files we want to \
	 modify
	Use GNU configure (or similar) solution
	More comprehensive installer -- possible step between script \
	 and new distribution?

Python:
	another thing to learn
	indentation facism causes trouble

Security:
	tripwire-like md5 hashing
		put in method to track kernel itself, and modules
		(and insmod, lsmod, rmmod, etc.)
		and, of course, all files not changing regularly
		md5 hash of hash software itself
	immutable bit for critical binaries
		only on ext2 filesystems
	be able to de-install perl and everything else
	What else do we want immutable?
	Find and remove questionable, unasked-for packages
		ie UUCP tends to install itself
		or maybe install additional packages
	Recompile monolithic kernel with loaded modules built-in
		depends on the user -- easier on server, harder on \
		 workstations
		hardened systems hardly need modules exchanged
		some drives ship only as modules
	Read-only filesystems -- category beyond paranoid
	Mount many partitions nosuid, noexec, read-only
	Put /tmp on ramdisk
	ACLs rather than permissions
	Security-minded recovery disk
		store checksums/hashes
		bootable
		critical binaries for investigation
		like trinux, w/additional features -- Bastille Trinux?
			SuSE also has one
		remove admin tools from system, leave them on recovery\
		 disk
	Change /etc/issue and /etc/issue.net to confuse hack attempts
	Alter other program banners to confuse/deter hack attempts
	Deception ToolKit
	Randomized user-generated application banners
	Edit /etc/rc.d/rc.local to not overwrite /etc/issue
	Prepare partitions from mini-partition-installer CD -- script \
	 before Red Hat even installs
	Put a file in listing modules to execute in order, then eval \
	 that. (Have modules register themselves in a table, then read\
	 said table.)
	Post-hardening, a system audit -- partitioning table, stuff \
	 from /proc, binary md5sums, etc., to be printed or stored \
	 elsewhere  -- some scripts do that now, use existing code!

User Interface:
	Put on ISO image, modify hard drive entirely from CD?
		prevents additional software installation
	Harden single package option -- for pre-hardened systemsG
	Purpose-specific automatic configuration
	Make all changes at end -- like a 'make config' and then a make
	A back-up feature to go back to earlier questions
	Dialog or Newt package, or the _menuconfig_ from Linux kernel \
	 code (text-mode GUI interface)
		Make menuconfig essentially can generate our Y/N \
		 answers, and we can feed them into our script without\
		 too much modification
	I/O and automation go hand-in-hand

Bugs / Concerns:
	Don't want to create empty, root-only .rhosts / hosts.equiv \
	 without an immutable bit available on the fs
		ok if just check .rhosts 0 bytes long

Jonathan Lasser (jon@lasser.org) (410)659-5333
Please direct all complaints to The Complaint Department.
Last Modified: 2000-June-21