The Gentoo vs. FreeBSD Security Showdown

K

Kasyx

Expert Member
Joined
Jun 6, 2006
Messages
2,565
Reaction score
1
Location
127.0.0.1
My friend and I are having a showdown between our operating systems of choice. He is going with FreeBSD, I, obviously, am going with Gentoo.

The rules are simple. We each set up our box with our chosen OS and whatever security measures we are able to implement, we then set up a basic shell account which the opponent has access to. Whoever gets root on their opponent's box first wins.

My setup of choice is going to be Gentoo Hardened, probably using SELinux.

Does anyone have any suggestions/strategies to lock down my Gentoo box as best as possible?
 
I've been speaking to Google about this on a regular basis. However I would like to get the input from our fabulous (think George Takei fabulous) MyBB Linux community.
 
A package is a package is a package. It doesnt matter that much which file system it runs on... so I am not too sure of thie point of something like this? If say a package like OpenSSL is exploitable in BSD, it should just as exploitable in linux.
 
w1z4rd said:
A package is a package is a package. It doesnt matter that much which file system it runs on... so I am not too sure of thie point of something like this? If say a package like OpenSSL is exploitable in BSD, it should just as exploitable in linux.
Click to expand...

The point is that we are bored, and we are nerdy.

Need I offer further explaination?
 
So the attacker's challenge is to escalate his privileges from an unprivileged local user to root, and the defender can do anything to prepare the machine?

That seems to make the defender's job very easy. He just needs to:
- make sure that the unprivileged user can't su/sudo to root (or SSH in as root), even if the attacker guesses password
- use disk quotas to prevent the attacker being able to write anything to disk
- make sure that as few processes as possible are running, particularly ones running as root (kill off everything but init and, if SSH is necessary, sshd)
- remove absolutely all software that's not critical to getting the machine to boot

If an attacker can become root on a machine like that, there's something very badly wrong with the operating system.

You could make it more interesting by requiring that the machine has to be doing something useful (like hosting some PHP application). Then the attacker's got something to work with.
 
drs said:
So the attacker's challenge is to escalate his privileges from an unprivileged local user to root, and the defender can do anything to prepare the machine?

That seems to make the defender's job very easy. He just needs to:
- make sure that the unprivileged user can't su/sudo to root (or SSH in as root), even if the attacker guesses password
- use disk quotas to prevent the attacker being able to write anything to disk
- make sure that as few processes as possible are running, particularly ones running as root (kill off everything but init and, if SSH is necessary, sshd)
- remove absolutely all software that's not critical to getting the machine to boot

If an attacker can become root on a machine like that, there's something very badly wrong with the operating system.

You could make it more interesting by requiring that the machine has to be doing something useful (like hosting some PHP application). Then the attacker's got something to work with.
Click to expand...

Those are some really good suggestions. We haven't totally defined all the rules as of yet, but we were contemplating making them LAMP servers, possibly each hosting the same version of a CMS or something. I'm gonna chat to him about it, because if the server is just sitting there not doing anything, it is pretty easy to ensure that no one gets in. Also, the shell account has to be pretty "default" - i.e. attacker will have read/write access in their home directory, but nowhere else.

Any other rules suggestions?
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X