ports = compiler = danger ?

[fluca1978]

Hi all,

This is not meant to critique the FreeBSD system as whole or the ports tree, it is just a curiosity. When I was a younger and green admin I was told that having a compiler installed on a production or perimeter machine is a bad thing. Now, the ports mechanism assumes you are able to install software compiling it, so isn't this possibly a risk?

Just curious...

 

[SirDice]

Yes, that's correct. You can build the base system without any compilers. But that also means you can only install packages, not ports.

 

[adamk]

You can build the base system without any compilers.

Huh? How do you build the base system if there are no compilers? Sure, you can install the base system without any compilers, but doesn't "build" mean that you're compiling it?

Adam

 

[Beastie]

Meh, deinstall build dependencies and remove compiler-related binaries from the base system. Reinstall/restore them when updating. :e

 

[SirDice]

Huh? How do you build the base system if there are no compilers? Sure, you can install the base system without any compilers, but doesn't "build" mean that you're compiling it?

You can do the building on another machine. Then export /usr/src/ and /usr/obj/ to install it.

 

[adamk]

True. I hadn't throught of that.

Still, though, you're building the base system with a compiler. Just a compiler on a different machine

Adam

 

[SirDice]

Yeah, I should have explained it a bit better. I always build systems that way so it's more or less second nature for me. Granted I never remove the compiler though, I'm not that security paranoid on my own machines. But for production systems I would definitely remove them.

No sense in giving a potential attacker all the tools needed to break stuff even further :e

 

[Dies_Irae]

Since the programs needed to compile (cc, gcc, g++, ld, etc...) are owned by root and belongs to the wheel group you could change their permissions, for example:

# chmod 550 /usr/bin/gcc

So only the users in the wheel group can use the compiler.

Obviously, if an intruder can gain access to the system using one of the accounts in the wheel group, the game is over.

Just an idea, never tested...

 

[DutchDaemon]

If an intruder can gain access, he can upload his own compilers too.

 

[SirDice]

If an intruder can gain access, he can upload his own compilers too.

True, but it is another step the attacker needs to make. No need to make it easier for them and provide a fully configured and functional build environment.

 

[MP2E]

True, but it is another step the attacker needs to make. No need to make it easier for them and provide a fully configured and functional build environment.

A very quick step... Is the effort required to make a hacker take 5 minutes longer and not compile anything worth it to you? It's definitely not for me, I always want a system compiler.

 

[SirDice]

A very quick step... Is the effort required to make a hacker take 5 minutes longer and not compile anything worth it to you?

Yes, it's no so much this one step. Security is like an onion, it has many, many layers.

 

[Sfynx]

I don't understand how compilers would give an intruder extra privileges. It's just another program really. Just don't setuid it?

Besides, how long would it take for a hacker to upload his own FreeBSD gcc toolchain to a box he just entered? If he's already root, it is a moot point anyway. If he isn't, he now can run a compiler anyway. IMO omitting a compiler is more trouble for the sysadmin than a nuisance for a hacker.

 

[SirDice]

I don't understand how compilers would give an intruder extra privileges. It's just another program really. Just don't setuid it?

Compilers aren't setuid. The reason is that your attacker could create a program that abuses (another) bug to elevate his privileges. Or create a simple proxy, a bot or whatever else an attacker could use.

Besides, how long would it take for a hacker to upload his own FreeBSD gcc toolchain to a box he just entered? If he's already root, it is a moot point anyway.

True.

If he isn't, he now can run a compiler anyway. IMO omitting a compiler is more trouble for the sysadmin than a nuisance for a hacker.

Not really. Not if I set home directories and /tmp to nosetuid and noexec. Then you have nowhere to run them from.

Like I said, security is like an onion, it has many layers.

 

[fluca1978]

I don't understand how compilers would give an intruder extra privileges. It's just another program really. Just don't setuid it?

Besides, how long would it take for a hacker to upload his own FreeBSD gcc toolchain to a box he just entered? If he's already root, it is a moot point anyway. If he isn't, he now can run a compiler anyway. IMO omitting a compiler is more trouble for the sysadmin than a nuisance for a hacker.

I agree that if the attacker has already gained root privileges he probably does not need a compiler, since he can even cross compile applications and upload them to the machine!
Anyway, having a compiler can become a risk for normal users trying to compile programs that will exploit privileges that can drop to a root shell. That was my only doubt.

 

[Sfynx]

If noexec is 100% fool proof, then I would leave the compiler on there, making sure only a select few can use it.

Sounds like a reasonable compromise. Those select few (or only root) can use the ports system like normal, executing only things at exec enabled locations that can only be written to by root, and the rest is forbidden.