Aegis Linux

ok, my interesting idea for a Linux server distribution that absolutely, positively has to be secure.

first- port over the jail() code from FreeBSD.

next, grab as many privledge seperated/priviledge dropping SUID programs from OpenBSD as you can. Also grab the OpenBSD version of SUID programs that can run without a SUID bit. OpenBSD is pretty good about making things use POSIX standards, so you can probably get them running on Linux with minimal porting.

run Stackguard 3 (uses Propolice style improvements,) FormatGuard, and Pointerguard on the kernel and all user-land programs.

use Raceguard as a kernel module. (edited, I forgot Raceguard was a kernel mod)

potentially, use a modified to work with *Guard, Libsafe (edited, forgot Libsafe was linked to glibc and had problems with Stackguard) Make sure programs using libsafe are still compiled with the *guard programs, as libsafe can miss some functions.

make sure all binaries are ELF relocatable/Position Independent Code and install and configure PaX and ASLR.

Install Solar Designer's non-exec stack.

install a Mandatory Access Control system, probably either Grsecurity if you need to make it easy for admins to use, or SELinux if you need more power, have experienced admins, and can spend time labelling everything as SELinux requires.

reduce the power of the root user via MAC's as much as possible.

use "proven secure" and audited programs where possible, such as postfix, qmail, Apache, vsftp, PureFTPD, etc. If sendmail or BIND is required by politics, use the OpenBSD configuration and patches for these programs to make these programs more secure. If a userland tool is particularly known for security problems, try taking an audited OpenBSD tool, perform port and audit on it for Linux environment differences, then install it in your system.

jail() everything you practically can, especially things with a questionable security history, SUID levels of access, or always-on network connections. jail() will confine root users, so SUID programs are ok.

use MAC's to back up the jailing of programs.

disallow loading of kernel modules and watch /dev/mem and /dev/kmem like a hawk, MAC'ing the hell out of it.

ok, that's the fancy and fun stuff you can do.

after doing all that, it should be virtually impossible to even get a toehold in your system via the conventional routes of stack overflow/heap overflow/format string/race conditioning you.

why?

First, most of your server programs should have good security design and are heavily audited.

secondly, even if an attacker finds a hole in the server program, they must get past either

1. for a stack overflow, the non-exec stack + StackGuard 3 + Libsafe removing many dangerous functions + PaX/ASLR to inject code.

2. for a heap overflow, Pointerguard + PaX/ASLR to inject code.

(edited- forgot Libsafe does not protect against heap overflows, stupid me)

3. for format string, FormatGuard + Libsafe + PaX/ASLR to inject code.

4. for filesystem race conditions, RaceGuard + PaX/ASLR. (edited, only filesystem races)

Even if it does happen, the fact you are jail()ing everything and MAC'ing everything should serve as a backstop and limit the priviledge escalation.

your biggest weakness is in the kernel. Kernel bugs are lethal, and I don't think Linux has them all shaken out yet. the *Guard family provides some protection, though, since they can be applied to a patched kernel.

maybe there should be more research into advanced methods of protecting the kernel, since if you lose the kernel you lose everything.

there are also other bugs that you are susceptable to... you are still vunerable to logic bugs/design flaws in the code, which can only be fixed by heavy auditing to find them.

this doesn't stop SQL Injection commands, Cross-Site Scripting, or any of the general HTTP attacks on web systems.

if you have the ability (maybe after you've sold a lot of these systems and made lots of money ;)) use an older version of the Linux kernel (2.4 sounds right) that's already had more scrutiny and pay a group of professional code auditors to have it throughly audited..... or at least to audit the most known dangerous parts. If you are flush with cash, have all the network programs audited as well.

one interesting idea that's going around is the digsig idea... you take digital signatures of all files on your system that shouldn't change, and an in-kernel module then alerts you in real-time if one changes.

there's also the Cryptomark idea by Immunix that allows you to sign programs and only run them if they haven't been tampered with.

you can also add the Prelude HIDS/NIDS system to monitor for instrusions and have it work in combination with SNORT IDS.

You should add stuff like portsentry to respond to port scan attempts.

syslog-ng allows for encrypted logging which makes it easier to send things over the network to a log monitoring computer. run good log grepping tools like swatch or checklog.

you can and should use the netfilter/IPTables firewall appropriately based on the situation.

passwords should be checked with cracklib, have appropriate expiration dates, and should be periodically dumped to a powerful central computer over a serial cable running a tricked-out version of John the Ripper that has a huge dictionary and as many varied word transformation as you can think of. if your dictionary isn't at least 25 megs in size, you aren't trying hard enough.

or you could use a jail()ed and MAC'ed off directory on the machine for using John the Ripper, although that's not optimal. if you use that, make sure you have a good shred or srm program in the jail()ed portion.

one interesting idea people are starting to use is using User-Mode Linux to seperate priviledges and avoid the use of a command shell on a service-only machine that doesn't need a shell.. this should be investigated as an option for users.

the use of "defensive" rootkits to monitor activity should be investigated as well.

credit should go to the Gentoo Hardened guys who have already put in place some of these things on Gentoo Hardened, the Immunix guys, Etoh, and other people coming up with this cool shit.

I follow most of that. Explain to me "defensive rootkits". I am familiar with the concept of normal rootkits.

defensive rootkits is applying rootkit technology for defensive purposes.

for instance... the HoneyNet project uses special Loadable Kernel Modules on Linux to hide resources from the attacker and allow transparent logging of the attacker's actions.

on Windows, some people are using loadable kernel driver techniques first used to create the first known Windows rootkit to try and impliment some of the interesting work first commonly done on Unix machines on Windows, such as PaX style stuff and Mandatory Access Control systems.

the main problem with that kind of stuff on Windows, though, is that the Windows kernel has so many ways around things that unless you are reading M$'s source, you can't really easily tell if the security feature you implimented can be bypassed.

it's really, really hard to retrofit that kind of stuff to closed-source OS's unless the company gives you access to the source....

plus, the companies that create the software charge so much that there's no real financial incentive not to just use Linux or the BSD's in many case, if you want to get the same coverage.

here's an idea...

RTLinux uses a custom-developed proprietary real-time OS kernel that runs a full Linux system as a low-priority process under the prop. kernel.

why couldn't somebody create a similar small open-source real-time kernel, designed with security in mind and with special abilities to protect the Linux kernel against attack and quick restart/save state abilities for the Linux kernel to quick restart if someone fires an exploit against the Linux kernel that trips the *Guard family of protections on the Linux kernel, since doing so would crash the kernel.

you would be leveraging the power and existing base of Linux with the added security of a kernel that is small (less code = less bugs) and that is heavily audited to a degree Linux cannot be, adding extra security.

or, you could just run the main system in a sandbox on a User-Mode Linux system... the User-Mode Linux provider could be as secured as the image being used on User-Mode Linux, but in addition the attacker has to get through the User Mode Linux sandboxing system to get total control.

ttt

Rob, what about contributing to the Bastille Linux project? You could really help your resume if you did. You could do some of those ideas yourself, without having to set up a whole new distribution.

I'm not good enough yet, frankly.

and Bastille is more about conventional hardening, not wild and wacky things that require modified compilers, kernel mods, etc...

True, Bastille is more conventional. But, you know conventional stuff too. And you are trying to get your foot in the door. If you read the posts on here they're all "How do I apply when I don't get experience" and "how to I get experience without the job?". Jobs at school are your way into the Unix world. Bastille Linux (or some of these other things) could be your way into the security world.