On Thu, 3 Jan 2002, Mark Tinberg wrote:
> You might wish to check out some of the existing work on
> Coyote Linux or LRP. There are several linux
> routers/firewalls on a floppy.
These are wonderful projects in their own right, and I may end up
using one of them. There's a little linux hacker inside of me that
wants to do it his own way, though :) LRP has prepackaged .lrp
files (last I looked), and I like having more control over where
things go, what permissions are there, etc. Using packages gets
the thing installed quicker, but leaves most of the tightening
steps to me yet. Also, I hadn't mentioned in the earlier post
that this half-baked plan has me compiling each resident program
with stackguard, just to provide another layer of protection.
> > The idea is that the linux box is a write-once box ...
>
> This is a good idea, but you would have to be prepared to burn
> a new floppy and reboot the firewall every time you wish to
> make a configuration change.
Yup. The hope would be that it wouldn't change much, although the
plan also inclues staying near the developers of each resident
program in order to stay on the latest & greatest version.
> > The kernel on the filesystem doesn't include floppy support; you
> > could extend this idea to making the floppy's filesystem minix and
> > then include only minix fs support.
>
> I don't understand you here, you could load the default system
> via an initrd but using minix doesn't buy you anything. In
> any event floppies can be write protected so not having floppy
> support in your kernel only makes your life more difficult.
> In any event if someone has the access to mount your floppy
> they have access to do many other bad things, including
> modprobing new stuff into your kernel.
Agreed, my point that you're replying to here is probably
overkill. The floppy itself would indeed be write-protected. I'd
like to reiterate that even console access should deny most
changes -- there would be no mount or modprobe program left by the
time the console sees a shell.
> > The permissions on the filesystem are stripped to bare minimums,
> > and then chattr -i'd.
>
> Remember to use something like LIDS to make the kernel and
> file attributes inviolate otherwise someone could just chattr
> +i your files, or access the raw device.
(I noticed my typo after I had sent the note -- I hope everyone
got the meaning that the files would be made "immutable" with
"chattr +i", not "-i"). LIDS and the idea of capabilities in
general is something that I would like to include, since it can
be another layer of minimum permissions.
> > The startup sequence runs a one-time init script which sets up the
> > firewall rules and services, and then removes most of the
> > remaining programs ("rm", "ipchains", "mount", etc).
>
> Again, you obviously aren't going to be doing any remote
> administration on this host anymore, but an attacker could
> always upload their own mount, ipchains executables (maybe
> even handcoded in ASM if space is tight).
Right, no remote admin. The "upload" attack is one that I've
thought a bit about. There's no editor of any sort, nor are there
any file manipulation commands (sed, perl, etc.) The only thing
left that I can think of is shell redirection. I'm going to use
the 'ash' shell, unless I can find another that's more
restrictive. The wrinkle is that I need the "echo" builtin to set
various /proc parameters, but I'd rather not have echo left
afterwards. I may see if I can disable the shell's echo, and put a
/bin/echo on the disk, use it, then erase it after bootup.
Oh, and there's no "chmod" on the system; that raises the bar for
actually getting stuff executed.
> > There would be no network access/login to the box -- console,
> > only, if you want to log in and attempt to do something. If you
> > want to make changes, you make them on the host system and
> > re-create the boot floppy.
> >
>
> If you have to network access to the box, only console, than
> many of you security precautions will not measurably increase
> your security, they will only frustrate you and make your job
> harder. There is a common misconception that being a big pain
> in the butt is synonymous with security. If you have no
> network accessible daemons then there is no reasonable way
> that someone could take over your box (the few unreasonable
> methods can then be more easily tracked down).
Agreed; "security in layers" is an overriding concept with this
project. The pain in my butt is mostly offset with my desire to
lock this box down as much as humanly possible; additionally, I
have shell and perl scripts that do much of the grunt work (using
objcopy --strip-debug on a list of executables to copy in, having
a shell script go through and set permissions, etc). I'm
encouraged by your comment: "there is no reasonable way that
someone could take over your box" -- that's exactly what I'm
aiming for. Of course, I suspect that real-world desires
(particularly on my part) will poke holes in the firewall in
various ways.
Network attacks (DoS) are something I can't do much about; the
firewall rulesets that went by on here a few months? ago had ICMP
rate limiting, which I think is a great idea. I may even apply
that to other protocols...
> > I like the idea of using a boot floppy because I can remove files
> > I don't need when I'm done with them; on a CDROM, I can't do that.
> >
>
> If you plan on removing files then you will have to make your
> floppy read/write. If someone does get access to the system
> then this lowers the bar for trojaning system binaries. If
> you don't plan on doing any admin work directly on the system
> then leave the filesystem readonly.
Sorry, I think I mangled concepts -- I don't actually remove files
off the floppy, because it's not a real filesystem -- it's got the
kernel followed by the compressed filesystem. It's mounted to /
after initrd. Sorry for the confusion; the system is pretty much
read-only.
> > So, I like imagining this setup against various attack scenarios,
> > such as the interesting example put forward by Kurt a few posts
> > ago where the attack mounts another filesystem over the top of one
> > of yours. In Jeff's half-baked plan, that wouldn't be possible
> > because the mount program is gone. There'd be no compiler, or even
> > room to upload a compiled binary. (A /tmp directory is created
> > with the minimum amount of space needed for temporary stuff during
> > bootup).
> >
>
> If the attacker can run programs on your machine, they can
> likely upload their own. Not having /sbin/mount wouldn't
> prevent them from issuing the mount() system call with their
> own binary. Just think how much fun it would be to upload a
> copy of busybox.
Yeah, if they can get it up there. I'm really hoping it's
impossible ^W difficult enough.
> > I'm calling it half-baked because I haven't finished it or the
> > article describing it (and I haven't done those because I haven't
> > finished working out how I want all the details to work).
>
> I think that you might have something wrt using chattr/LIDS,
> readonly filesystems and not doing config tasks on the same
> system as is doing the packet filtering. You can make the
> system almost impossible to break into and to then
> subsequently trojan. Just don't make the system too much of a
> pain to use, at least without good reason, and be aware that
> if you are burning new disks everytime you make a config
> change you might be creating extra downtime.
Exactly!
Thanks for your comments on the idea, Mark -- I look forward to
having something that I can test and show in the real world!
If/when I do get this finished, I may ask here if there are
volunteers to crack it -- of course, you needn't crack /my/
machine, I could simply send you the floppy image to write to a
diskette, and you could boot your own target system.
-jeff
--
Last week, scientists announced the first-ever cloning of a human embryo,
which they hope to mine for stem cells to treat diseases. What do you think?
"At last, the underpopulation crisis has found its magic bullet."
Carla Rayner, Homemaker.
