# ports = compiler = danger ?



## fluca1978 (Oct 19, 2011)

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 (Oct 19, 2011)

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 (Oct 19, 2011)

SirDice said:
			
		

> 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 (Oct 19, 2011)

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


----------



## SirDice (Oct 19, 2011)

adamk said:
			
		

> 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 (Oct 19, 2011)

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 (Oct 19, 2011)

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 (Oct 19, 2011)

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 (Oct 19, 2011)

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


----------



## SirDice (Oct 19, 2011)

DutchDaemon said:
			
		

> 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 (Oct 19, 2011)

SirDice said:
			
		

> 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 (Oct 20, 2011)

MP2E said:
			
		

> 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 (Oct 24, 2011)

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 (Oct 24, 2011)

Sfynx said:
			
		

> 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 (Oct 24, 2011)

Sfynx said:
			
		

> 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 (Oct 24, 2011)

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.


----------

