# FreeBSD security - compilers



## chavez243ca (Feb 24, 2011)

Unix best practices WRT security often mention removing compilers, esp. from systems that sit in a DMZ.  What is the FreeBSD community's stance on this?  I do most of my package management with the ports system, removing compilers would significantly alter the way I manage the hosts.

How about chmod 700 things like gcc?  Would that increase the overall security posture without breaking anything?

Thoughts?


----------



## xibo (Feb 24, 2011)

A compiler is not a security threat - at the point where an intruder can make use of a compiler virtually all was lost long ago.


----------



## chavez243ca (Feb 24, 2011)

I think the line of thought is that a compiler aids in the establishment of a rootkit.

From what I have see some of the old tactics would be to gain access to the system, even with limited privs, upload rootkit.c to something like /tmp and compile into the kernel


----------



## SirDice (Feb 25, 2011)

The trick is to do the building on a different machine and create packages. Then you can transfer the packages to the 'hardened' machine. 

From a security standpoint it's best to remove any compilers from production machines.


----------



## xibo (Feb 25, 2011)

I was just quoting from OpenBSD's FAQ (section 4.7 subsection "I don't want to install the compilers"), which seems quite reasonable to me.


----------



## danbi (Feb 25, 2011)

The point to remove compilers is that, on a relatively unique OS, one needs to only transfer portable source and have whatever software. Mostly useful on proprietary systems.

FreeBSD, being so popular, does not benefit much from removing compilers. Anyone can download any version of FreeBSD and compile whatever they want on their own desktop computer or easier yet, in a VM.


----------



## mk (Feb 25, 2011)

danbi you got that one wrong. This as with jails - you put in jail only what you need to run your services. The difference is that is not a jail rather real machine. By removing infrastructure like compilers you limit the attacker by not letting him to use your system against itself. Even better - if it have fast cpu then why not compile world+dog on it. Removing commands is even further extension of this. Using src.conf you can easily control the process.


----------



## DutchDaemon (Feb 25, 2011)

All danbi is saying is that an attacker who does have access can simply upload the _pre-compiled program_, instead of compiling it on the attacked system. All the attacker needs is the same FreeBSD version, including compilers, on their own machine/VM.


----------



## qsecofr (Feb 25, 2011)

Maybe from a development methodology or procedural standpoint you wouldn't want to compile in a production environment.  Development, SQ, and production environments may all be logically & physically separated.  Ideally, the objects in production are the same as those tested in SQ, and there are no production object/source mismatches.  Differences in environment could affect a build such that the object in production doesn't run as intended.  This comment is not specifically pertaining to a DMZ, but more generally.  All threats are not always malicious.  Non-malicious programming bugs can be just as much a threat, or more even.


----------



## danbi (Feb 26, 2011)

Certainly, I agree with qsecofr. However the original question was whether presence of compilers would present security risk. I still stand the opinion, that the lack of compilers cannot stop an determined attacker in any way. Proper security measures and more importantly, processes can.

From my own experience:

In the days of BSD/OS, I had a (large) number of machines, that were specifically configured without any build tools. The primary reason was of course resource preservation, but at the time I did feel safer that way. I also happen to have pet hacker. That person had as the goal of their life to break into some of my machines.
As he was quite persistent, that gave me the perfect opportunity to observe and study this behavior 
As BSD/OS was commercial software it was not available for download, yet it was enough widespread. That prompted my hacker to go research for an available BSD/OS computer, break in there and have access to the compiler (and libraries). He was then lucky to live until the telnet buffer overflow bug happened and could successfully gain root access to one of my machines. Well.. he didn't know I don't use telnet to access there, nor any of the methods he envisioned to trojan -- and my sync process distributed patched binaries -- yet, the hacker had their 15 minute victory. So, not having compilers did not help at all. Proactive monitoring and management did. It would have been nightmare to patch that number of system that fast manually...

Later attacks, most of them were using interpreted code. So again, no need to have an compiler online. They were unsucessful for other reasons anyway.

Quality control is however completely different thing. My observation unfortunately indicates, that some very respectable and supposedly security-minded companies have failed to realise, that you need quality control at all levels -- and this means very knowledgeable people at all levels. Including the people who hit the last ENTER. 
It doesn't help you have separate build, test, qualify and deployment systems, if at any time there is weak security.


----------

