Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Ultimate write security?

By Miniluv in Technology
Sun Dec 10, 2000 at 11:53:48 AM EST
Tags: Security (all tags)
Security

This is an idea I've been trying to work out in my head for a few months, and have almost got it to the point of actually trying it on a machine to begin ironing out the application issues. The goal is to produce a machine suitable as a firewall, using FreeBSD as a base, that is at worst only temporarily compromiseable.


The key to the entire thing, in my mind anyhow, is taking FreeBSD's memory file system (MFS) and combining it with a write only media to boot from. In the case I'm trying to finalize a way of implementing it would be a cd-rom burned with a complete file system image of the core files necessary to boot and process packets. During OS intilization this would then be mounted into the MFS and init would finish bringing up the OS.

The advantages I see are these:
1) Faster overall OS performance as everything is a read from RAM or a write to RAM.
2) No writeable media to be compromised with tojans, root kits, or substitute configuration files.
3) In the event of a comrpomise a simple reboot will remove all traces of the compromise, and a simple substitution of the cd-rom with updated configurations can remove the security holes that allowed the compromise.

What I'm looking for here is some discussion from outside my head as to the pro's and con's...and possibly some suggestions about what's absolutely necessary on this machine to fit into the minimum of RAM. My intention is after people here have helped me refine the goals and broad implementation ideas, to work up a more detailed implementation plan and write that up as well. If that goes well I'll also write a third story here with details, or a link to details, of the installation and perhaps some performance benchmarking.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Is a write only OS in MFS a good idea?
o Hell yeah...rooted until rebooted rocks. 20%
o Maybe...lots of questions still unanswered. 30%
o Definitely not, there's no advantage. 7%
o Definitely not, it's impossible to do. 3%
o Inoshiro thought of it first. 10%
o | @m 1337 h@X0r, i 0VV|\| j00!!!!111 28%

Votes: 85
Results | Other Polls

Related Links
o Also by Miniluv


Display: Sort:
Ultimate write security? | 48 comments (40 topical, 8 editorial, 0 hidden)
Great Idea (1.58 / 12) (#1)
by k5er on Sun Dec 10, 2000 at 01:21:51 AM EST

I don't know much about BSD or security to suggest anything helpful, however, this seems like a great idea!
Long live k5, down with CNN.
People have been doing this for years (3.40 / 5) (#4)
by kaboom on Sun Dec 10, 2000 at 01:40:37 AM EST

Check, for example, the linux-kernel archives. I remember a Mr. Alan Cox (you might have heard of him ;-) a couple of years ago, mentioning doing this (though, of course, running Linux off of CD) to protect further against 1337 h@X0r

Some advantages, though not perfect (of course). (3.80 / 5) (#5)
by Christopher Thomas on Sun Dec 10, 2000 at 01:42:33 AM EST

This proposal would certainly work.

However, the box could still be temporarily compromised, and could possibly go for quite a while without this compromise being detected.

Back when a friend and I were talking about doing something similar with Linux, we were planning to set a cron job to reboot the server every morning at 5am. This would wipe anything planted that we hadn't noticed, and the *absence* of a reboot would be a nice tipoff to a rooting (or hardware or software failure; both happen).

it has already been done (none / 0) (#21)
by SEAL on Sun Dec 10, 2000 at 05:28:15 AM EST

Look at any number of Linux distribution-on-a-floppy systems. For a router, you can look at the Linux Router Project. For security analysis, there's Trinux. I know there are a couple others out there as well.

These distributions simply create a ramdisk at boot time and load their packages into it. You don't even need to have a hard drive in your system. Of course, you could also go for a hardware router and leave the PC out of the picture entirely ;)

SEAL

It's only after we've lost everything that we're free to do anything.
[ Parent ]

Some thoughts (3.85 / 7) (#6)
by radar bunny on Sun Dec 10, 2000 at 01:54:00 AM EST

1. shouldn't it be read only, not write only? (i admit im nitpicking here-- or maybe I just misunderstood you) :o)
2. since your working with the size of ram, you would want to keep it under 128, or 96 megs even. This would mean no purty X stuff (which wouldn't be needed anyways for a simple router/firewal/server type of box)
3. You would want to stay on top of patches and updates and update/reboot the box before the break in occures. After all, it only takes a reboot.
4. Instead of Freebsd, you might want to seriously look at OpenBSD. Check out this link for required space. You can get a good system up and running with as little as 33~ megs of space. This means you could get away with 64 megs of ram easily. Also, openBSD hasn't had a remote security hole found in the default installation in over 3 years. So if security is your concern, I would seriosuly start here.

Good points... (3.00 / 1) (#14)
by Miniluv on Sun Dec 10, 2000 at 04:44:19 AM EST

Yes, I meant read-only..I'm a doughhead in that respect. I started with FreeBSD because it's what I'm most familiar with, and honestly in my experience FreeBSD is just as secure when well configured as OpenBSD. This is definitely intended as a single/small group of purposes server...ie a firewall or dedicated web server, so yer right about being able to shoehorn it into a small space. I know there are several projects revolving around embedded FreeBSD, because it can be crammed into a tiny disk-on-chip fairly easily as well.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]
33 megs? What would you do with 33 megs? (3.50 / 2) (#16)
by bgalehouse on Sun Dec 10, 2000 at 04:47:23 AM EST

Make root the cd, /etc a mount point floppy which normaly has it's write protect tab in use, and mount /tmp as 1 meg ramdisk. The cd will probably have like 10 megs or less if you only put on what you need to admin a firewall - ssh, ipf, bash, vi, super minimalist kernel, maybe a custom init, etc. I bet it'd run just fine with 8 megs of ram.

Log to printer or to some other (hardened) machine, or to both (maybe with different levels of verbosity).

But, as has been pointed out here, it has been done. Probably easier to start with one of the minimalist distros. Linux router project, picoBSD, or whatever.

[ Parent ]

Why OpenBSD? (4.00 / 1) (#45)
by jmcneill on Thu Dec 14, 2000 at 11:44:09 AM EST

Also, openBSD hasn't had a remote security hole found in the default installation in over 3 years. So if security is your concern, I would seriosuly start here.

Why does that matter for this machine? The thing won't be running any services, so remote security worries are really moot. FreeBSD, NetBSD, or Linux will do just as good of a job. All of them can fit into a small enough space if you only install what's absolutely necessary.

NetBSD 1.5 ships with no services running by default, so it might be a useful thing to look at as well. Either way, any of the above mentioned operating systems will do providing that they're configured properly.


``Of course it runs NetBSD.''
[ Parent ]
You have a couple issues to work out (4.60 / 5) (#7)
by ghjm on Sun Dec 10, 2000 at 02:04:37 AM EST

1. Logging. Of course, everyone's situation is different, but every firewall I've ever been personally involved with does some sort of logging, usually quite extensive. A truly elegant solution would provide for some sort of write-only logging that can't be compromised, edited, deleted etc. once written. In other words, a printer. :-)

2. Configuration. You gloss over this, but come on, you're saying I have to remaster and re-burn a whole new CD every time someone wants to make a slight change to the permit/deny rules? Not really practical. Maybe if you built some tools, though...like a multi-session CD where you can write and rewrite the /etc directory? Or for that matter, a CD-RW (rewritable) is just as read-only as a CD-R if you only put a CD-ROM reader in the firewall machine.

3. Compromise detection. Yes, you can guarantee that the boot media can't be compromised without physical access, but that doesn't mean you aren't rooted. Given an exploitable vulnerability, some kiddie can re-root you whenever you reboot, until you figure out what's going on and fix it. In a sense, having a writable filesystem actually helps you detect attacks because you can run tripwire (or equiv) and notice when something on the filesystem changes unexpectedly. Forcing all attacks to be in-memory means you are safe from a large class of attack, but _more_ vulnerable to the remainder. Unless you do something about it, though I can't at this moment imagine what that might be.

-Graham

Floppy? (5.00 / 1) (#9)
by Greyjack on Sun Dec 10, 2000 at 02:30:10 AM EST

2. Configuration. You gloss over this, but come on, you're saying I have to remaster and re-burn a whole new CD every time someone wants to make a slight change to the permit/deny rules?

Well, perhaps you could keep ipf.rules and ipnat.rules (and any others that would be applicable) on a write-protected floppy; would be easy to change 'em that way if you needed to make a small tweak.

Ludicrously simple approach: after you move everything from the CD into the MFS, just copy the contents of the floppy into /etc, on top of whatever else might be there already.

--
Here is my philosophy: Everything changes (the word "everything" has just changed as the word "change" has: it now means "no change") --Ron Padgett


[ Parent ]
Assuming you trust the write-protect logic. (none / 0) (#35)
by ghjm on Sun Dec 10, 2000 at 09:58:11 PM EST

I don't know about modern PC floppies, but I recall that many of the old 360k 5.25" floppies did not enforce write protection in hardware; the write protect line was readable by the OS, which was supposed to respect it; but if the OS decided to write anyway, nothing failed. The next step would be to put a modified floppy drive in the firewall, with the write logic physically disabled in some way. I'm assuming this would be as simple as clipping a lead, or at worst scratching out a trace, but I'm not really basing this on anything. Anyway, if you could figure out how to do it, you would have a read-only floppy drive, so you wouldn't even have to set the write-protect tab on the diskette - just take it out and write to it from a different machine.

Come to think of it, I've seen hard drives with write-protect jumpers on them. Not recently, but it wouldn't surprise me if you could track one down. That would save you the trouble of having a ramdisk et. al., just write protect the hard drive. Once again, if you can't find a drive with this feature, you can probably implement it yourself with some schematics and a good sharp razor blade.

-Graham

[ Parent ]
My plans... (none / 0) (#18)
by Miniluv on Sun Dec 10, 2000 at 04:51:59 AM EST

1) Logging is definitely essential..there are tools out there for doing remote, encrypted logging. Unfortunately I cannot locate them off-hand, but I know there's mention of them at Security Focus.
2) That was one of the things I was pondering myself, and you raise a good point that a CD-RW will definitely serve the purpose...I always seem to forget that distinction.
3) To my understanding a utility like tripwire could still be run to detect changes in the file system, and still report to a remote log/pager/etc as with a normal system. In fact, any form of static modification monitoring would still work, as long as it was on the cd to be launched by init at boot. Am I wrong about this, if so please let me know why...

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]
Re: My plans... (none / 0) (#26)
by UrLord on Sun Dec 10, 2000 at 01:04:18 PM EST

1) This would involve some sort of trust between the hosts right? Trusted hosts leads to compromises spreading throughout a network. I could be wrong and I'm sure you could keep that trust to a minimum (/etc/hosts.allow syslog:<logging server ip> with a default all:all in hosts.deny).
2)doesn't need comment :)
3)I don't believe tripwire could tell if a change was done in memory. The problem is, unless someone changed something on the cd itself tripwire would think everything was still the same. Would the MFS be the filesystem you wanted to use tripwire on? Does tripwire support monitoring a filesystem in memory? If I misunderstood something, I apologize, it's lunch time :)

We can't change society in a day, we have to change ourselves first from the inside out.
[ Parent ]

My understanding... (none / 0) (#33)
by Miniluv on Sun Dec 10, 2000 at 08:34:28 PM EST

Tripwire monitors the hash of a file to look for changes on a filesystem. MFS is a file system simulated in RAM, but presented by the OS to it's applications as an actual file system. If my understanding of the above is in fact correct, I cannot see any reason that tripwire or a similar program wouldn't run properly.
There are ways you could get around "trusting" the firewall, such as a dedicated VLAN link through a managed switch to that logging host, so no one could forge source IP's from another machine because the switch'd drop 'em. There are others of varying degree's of difficulty that are implementable too. Logging is definitely something I'll address as I continue to shape my plans.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]
Re: My plans... (none / 0) (#41)
by UrLord on Mon Dec 11, 2000 at 07:23:42 PM EST

Cool, I wasn't sure how it would all fit together. I remember seeing an article or two that mentioned using a bootable cd in this fashion. I think it was sysadmin and they were using it as a honey pot. If I remember I'll take a look to see if I can find the article.

We can't change society in a day, we have to change ourselves first from the inside out.
[ Parent ]

logging (none / 0) (#34)
by tbcidy on Sun Dec 10, 2000 at 08:38:12 PM EST

If you are using syslogd to log you can always use @hostname to log to hostname rather than to the localhost.

[ Parent ]
Write protect switch (none / 0) (#42)
by ucblockhead on Tue Dec 12, 2000 at 01:43:56 PM EST

What he really wants is not a CD-R drive but a hard drive that has a writeprotect switch mounted on the front of the box. From what I understand, most hard drives actually have write protect functionality built in, but it isn't typically used. This way, configuration changes would be a matter of flipping the switch, making the change, and flipping the switch back. You'd want to reboot clean first, though, in case the in memory version was compromised.

(But I agree with your point about tripwire and such.)
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

That's what I do. (4.00 / 3) (#8)
by Sylvestre on Sun Dec 10, 2000 at 02:13:21 AM EST

Check out Airgap Networks and ProWall. I worked on the first one.
-- Firearms are the difference between free people and subjects.
PicoBSD (4.75 / 4) (#11)
by sinclair on Sun Dec 10, 2000 at 03:22:10 AM EST

So good, in fact, that I made a firewall this way a couple years ago. But I can't take any credit for the idea; it's a project called PicoBSD. PicoBSD's makefiles and scripts easily build your custom kernel, plus a multi-run binary that incorporates many basic utilities, which then get wrapped in a filesystem image ready for you to write to a floppy disk. Yes, a floppy disk. At runtime, PicoBSD sets up and runs from an MFS, so your floppy can be read-only.

The firewall I set up ran on a Pentium with 8MB of RAM, and was not exploitable, because it did not accept network connections from anybody. It just passed packets. If somebody had managed to break in, there weren't enough utilities (or space) to do any damage, and since the system booted from a floppy disk, I could have updated the system configuration easily.

The best part of it? PicoBSD is free, and already included with the FreeBSD source code.

Whoops. (3.00 / 1) (#12)
by sinclair on Sun Dec 10, 2000 at 03:26:03 AM EST

I left out the first sentence: "That's a good idea." Sorry!

[ Parent ]

Hadn't heard about that... (3.00 / 1) (#15)
by Miniluv on Sun Dec 10, 2000 at 04:47:06 AM EST

I kinda figured the idea wasn't fresh, though I myself hadn't read about it anywhere. I'll have to check out PicoBSD...though I'm also looking to build some sort of configuration interface that'll let you select services prior to building the image to burn to CD. I see this as something possible for more than just a firewall that passes or rejects packets, as it might be useful to be able to tune firewall rules within the MFS without reburning a cd.
And despite it being already out there, I'd also like to build this myself from scratch without referring to their project for the chance to learn more about how it's done, which is part of why I'm asking for the type of feedback I'm getting. Thanks much for your advice.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]
CD-ROM (3.50 / 2) (#19)
by sinclair on Sun Dec 10, 2000 at 05:10:59 AM EST

PicoBSD does have a method to select services before building the floppy disk image, and an interface to twiddle firewall rules while it's up and running. It's called a text-editor. :-)

With all the space CD-ROM to work with, I'm sure you could do one heck of a lot better. For myself, though, I'd stick to the same principles as on the floppy disk. Namely, I'd go with a box that accepts no connections at all from the outside interface, nor from the internal interface, if possible. If it did accept connections from the internal network, I'd only put on a carefully limited set of tools.

Good luck.

[ Parent ]

read-only not enough (4.00 / 1) (#38)
by mikpos on Mon Dec 11, 2000 at 09:57:23 AM EST

Mounting something read-only would not be enough; the medium has to be physically read-only only (which can be emulated quite nicely on a floppy by ejecting it the second it's finished copying it into a ramdisk). The reason is that if someone were to get root, it's mighty trivial to "mount -o remount,rw".

Unless, of course, by "read-only" you meant that you slid that little plastic slidy thing on the disk to "read-only", or something to that effect. :)

[ Parent ]

Media and RAM... (2.40 / 5) (#22)
by pb on Sun Dec 10, 2000 at 05:39:28 AM EST

If your OS is designed correctly, then eventually everything *should* be in RAM, provided you have enough. Linux practices pretty aggressive caching, and I gather the *BSD's do the same.

However, I'd much rather load it all at once if I were booting from a CD; their seek time would kill you otherwise! :)

Also, it would be possible to do both: load / (or whatever else you need) into RAM, and then have extra stuff mounted on the CD...
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
loading into RAM (3.00 / 1) (#28)
by mikpos on Sun Dec 10, 2000 at 03:23:52 PM EST

The benefit of loading everything into RAM is that then you can mount it read-write. If you were to mount everything on solely read-only media, then you would have difficulties doing simple things like mounting (since it would be unable to write to the mtab). The disadvantage is, as you point out, that you would have copies of everything in RAM (since files on the ramdisk would be cached in RAM).

[ Parent ]
Linux booting from CDROM (2.00 / 3) (#24)
by TuxNugget on Sun Dec 10, 2000 at 07:17:04 AM EST

It is possible to make a linux system without a hard drive.

You can burn an ext2 filesystem onto a cdrom, and have a boot floppy that indicates /dev/sr0 (or similar) as the root filesystem. This read only root filesystem creates and mounts a ramdisk for spooling and temp files.

I managed to make something that would boot and spin the CDROM almost continuously. It would live if you left it alone, but if you tried to use it, it had a tendency to hang as some scripts assumed root could write files in strange places and became unhappy when they couldn't.

Of course, this is just screwing around. Someone who really knew what they were doing could probably make a viable read-only, hard diskless linux distribution.

DemoLinux (3.00 / 1) (#30)
by cgrabe on Sun Dec 10, 2000 at 06:02:15 PM EST

I've been using DemoLinux 2.0 for some time and it works very well. The only problem is StarOffice is in French. It's based on Debian and includes a full linux system with X, Netscape, StarOffice, games, utilities, just about anything you need. The entire thing boots from one cd-rom. More info at www.demolinux.com

[ Parent ]
custom linux CDs (4.00 / 1) (#36)
by TuxNugget on Mon Dec 11, 2000 at 02:16:43 AM EST

I'm sure the demolinux folks put some thought into it and have something that works
better than I can make in my spare time.

Of course, part of the problem is that you are not only committing to a specific distribution,
but also specific hardware, and specific configuration settings.

Seems like someone, oh like VA Linux, could make a specialty biz out of putting
together exactly what people needed to have a good read only linux appliance.



[ Parent ]
configurable (5.00 / 1) (#43)
by cgrabe on Tue Dec 12, 2000 at 05:24:13 PM EST

DemoLinux has worked perfectly on almost every computer I've used it on. I've used it on many boxes, and all but two ran at at least 1024x768 high color and recognized the hardware. The others ran at 640x480 vga just fine. There is an option to "anchor" it to your harddrive. It places a ~100MB file on your hard drive that contains settings, personal files, etc. if you so choose. If you wanted to change default settings, you could always change the config files or even software packages and reburn the cd.

[ Parent ]
Linux running from a CDROM (none / 0) (#47)
by Bernie Fsckinner on Fri Dec 15, 2000 at 05:55:35 AM EST

www.thinknic.com Ellison's second incarnation of the network computer claims to run Linux from a CD (I haven't had a chance to verify it for myself yet, but am hoping to sometime this year)

[ Parent ]
Finnix: RH-6.1 w/root filesystem on CD (none / 0) (#48)
by maynard on Fri Dec 15, 2000 at 09:52:40 PM EST

I'm using Finnix as an installation mechanism for a couple hundred desktops at MIT (these are NOT Athena workstations). It gives you a mostly complete Redhat-6.1 OS bootable off of the CD and the root filesystem included. Simply boot the CD, point it to the CD device at the lilo prompt, and off you go. From there one need only load the proper kernel module for the network interface and configure an IP address.

The installation model is to boot with finnix, partition the disk, configure networking, mount a remote NFS install tree, tar everything over preserving permissions. Real simple. The reason I'm doing it this way is because we're using a hacked RH-6.2 template which inlcudes a special kernel with FreeS/WAN IPSEC support, Helix GNOME, StarOffice 5.2, a bunch of CERN scientific libraries and applications, etc etc etc. God how I would hate to do each machine like this by hand using the Redhat installer, and I didn't want to bother making each of these an RPM. Plus, I don't want to bother with RPMs anyway, I plan on using cfengine to maintain consistency between desktops and our template server.

Anyway, Finnix is exactly what you're looking for.

--Maynard

Read The Proxies, a short crime thriller.
[ Parent ]

Interesting (2.00 / 2) (#25)
by maketo on Sun Dec 10, 2000 at 11:47:24 AM EST

This sounds interesting -> is there any URLs to point to read on how to set up one of these babies - say, PicoBSD?
agents, bugs, nanites....see the connection?
Don't know about xBSD, but for Linux... (3.00 / 1) (#27)
by nstenz on Sun Dec 10, 2000 at 02:17:03 PM EST

I have yet to set up the firewall I will soon be building, and I'd rather use xBSD than Linux just because, so I could use some links as well. But if anyone's looking to use Linux in a firewall/NAT router, check these two out:

SmoothWall sounds like a nice idea... I was stuck with a WebRamp analog router for a long time - it worked fine, but wasn't overly secure and cost me >$250. By the way, if anyone wants to buy it, it's got 1 56K modem and a 4-port 10Mbit hub, and can multilink with a 2nd external modem... =)

I almost prefer the simple hardware solutions because they do have a few simple configurable firewall rules - but I'd never use them in a server/production environment.



[ Parent ]
Con? (3.50 / 4) (#29)
by interiot on Sun Dec 10, 2000 at 04:56:52 PM EST

The firewall can easilly be un-rooted by rebooting it, but that doesn't mean much for the inner computers that became exposed to the cracker.

Granted, between the time that you reboot and the guy re-roots you, you'll have a trusted network monitor to watch for any backdoors on the inner computers. But that could be done anyway with a separate CDROM-only network monitor.

Write only media? (1.00 / 2) (#31)
by joto on Sun Dec 10, 2000 at 06:38:59 PM EST

...combining it with a write only media to...

Sure, where do you buy yours...

suggestion (1.66 / 3) (#32)
by brad3378 on Sun Dec 10, 2000 at 08:29:58 PM EST

As much as I hate to endorse Zip Drives, I have to admit, that a zip 250 would probably be the perfect solution. I don't know much about the write protection, but Floppies will let you flip the tab to make them read only. I think there's a similar way to do that on a zip disk, but admittedly, I don't know how. keep us posted!

zip disk protection (4.00 / 1) (#37)
by joto on Mon Dec 11, 2000 at 08:45:51 AM EST

The zip disk write protection is done in software. So it's not really useful for this. You could just as well "mount -o ro" your harddisk, it wouldn't be any safer.

[ Parent ]
Write-only media (2.50 / 2) (#40)
by mosburger on Mon Dec 11, 2000 at 01:05:10 PM EST

I used to work for a hard-drive company (I wrote servo code for SCSI drives). I'm quite certain that you could write-protect their drives with a jumper. Might be easier to start out that way than to use a more unconventional type of storage media...

It would be cool if you could somehow use a CDR for logging, that way , you couldn't erase it!

--- I want to be different, just like everybody else. ---

Linux Router? (4.50 / 2) (#44)
by bob_t_bold on Wed Dec 13, 2000 at 10:22:18 PM EST

How about the Linux Router project. While not *BSD based, it works on basically the same principles, ie., lock it down, don't run anything except for packet inspection and forwarding, run out of memory, etc. There is more info at http://www.linuxrouter.org. Robert

LRP (4.00 / 1) (#46)
by dorward on Thu Dec 14, 2000 at 10:21:45 PM EST

Part of the LRP site suggests running the system from a 1.44 floppy disk with the write protect tab in read only mode.

[ Parent ]
Ultimate write security? | 48 comments (40 topical, 8 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!