Delete compilers to cross compile

[revzalot]

I want to delete the compilers in server and want to learn to cross compile from a linux workstation.

[jggimi]

Why? Because it will feel so good when you stop trying it?

1. Removing comp*.tgz from an OpenBSD platform will not improve security. Anyone who can gain shell and network access can bring a compiler or any other needed tool with them.
2. The build environment is unique. The built-in gcc tool chain is customized to include OpenBSD-specific features, such as ProPolice.
3. Cross compilation of any kind -- even OpenBSD to OpenBSD across architectures, is unsupported. The cross compilation tools used by developers are only used when migrating to new archs, and are neither kept up to date nor documented, specifically to prevent users from attempting to use them.

[ocicat]

Originally Posted by revzalot

I want to delete the compilers in server and want to learn to cross compile from a linux workstation.

Why?

As I understand the lore, this is one of the sticking points Theo had with the NetBSD boys -- cross-compilation is a source of untold errors which can be very hard to track down. Here are some threads from the archives of misc@ you should understand:

• http://marc.info/?l=openbsd-misc&m=106416426603341&w=2
• http://marc.info/?t=107887030400003&r=1&w=2
• http://marc.info/?t=107656660100008&r=1&w=2

Cross-compiling requires significant knowledge of both platforms in order to be successful. Finding someone conversant in both who will has the same interest to see this to the end will be difficult to impossible. If this is a subject you are very passionate about, you should begin studying what kind of object files GCC emits. Following that, study GCC's linker -- in depth.

[jggimi]

For a brief discussion of OpenBSD cross compilation issues, see pages 7-9 in http://www.openbsd.org/papers/mips32-openbsd.pdf

[Oko]

Originally Posted by jggimi

[*] Removing comp*.tgz from an OpenBSD platform will not improve security.

That is not true. Removing compiler from the firewall solution is a very good security measure.

The rest of your post is right on money. If he doesn't want compiler on his production machine he should have an extra machine and use it for compiling and updating his production machine. The second computer will run identical architecture of course so properly speaking that is not cross compiling.

Real cross compiling is possible but it is used only by developers to introduce new architectures. Even packages for VAX or very slow ARM architecture are compiled on real hardware. They are not cross compiled.

The only platform that I know of which uses cross compilation on regular basis is NetBSD.

I do not know where that cross compiling on Linux came from as Linux in practical terms runs only on i386/amd64 and more recently some embedded platforms (support for other architectures is a big joke).

[jggimi]

Originally Posted by Oko

That is not true. Removing compiler from the firewall solution is a very good security measure.

While reasonable people may differ on this subject, yours is the minority view among OpenBSD users and project developers. It's been discussed ad infinitum. Here's a thread from 2006, which was, I think, one of the more recent times:

http://marc.info/?t=115640337900001&r=1&w=2

[revzalot]

Wow very informative posts. The reason of doing this is for security reasons. I'm looking for better ways to secure my mail server which will be in a dmz. I've read many posts of deleting the compilers to "harden" the server. Another one is 'chflag' certain files. Just being paranoid.

[BSDfan666]

Originally Posted by Oko

That is not true. Removing compiler from the firewall solution is a very good security measure.

I'll have to side with jggimi, crippling the functionality of your router will not improve security.. if someone manages to get a shell account on your system they can still setup a working build environment.

[jggimi]

Originally Posted by revzalot

...for security...

I agree with the majority of users (and developers) that not having comp*.tgz available does more harm than good -- in that admins who don't have maintenance tools available don't maintain properly. And an out-of-date system has more risks than an up-to-date one, if everything else is equal.

If, like some, you believe it "enhances" system security to not have your tool sets on board, that's fine ... as long as you have the tools on a second machine of the same architecture, so that you can build a release(8) for your production platform whenever needed.

As for file flags ... yes, they can be very helpful. I use "uchg" or "uappnd" for for things I don't want damaged in $HOME or other common working directories, that might be susceptable to a finger fumble.

But I think that on a system which is already limited -- we typically don't invite random people to have shell accounts on our most carefully controlled systems, and if we're careful, we only allow strong authentication (such as public key) methods for log on to those few shell accounts present -- that the system flags and securelevel 2 cause more trouble for an admin than their value. Do you really want to shut down critical services in order to jump into single-user mode for otherwise non-disruptive maintenance tasks? See white's Add HD thread for an example of a slap-on-the-forehead caused by an admin attempting to "harden" a platform.

Why do I say they're more trouble than value?

See this misc@ thread regarding file flags and securelevel:
http://marc.info/?t=121450215700005&r=1&w=2

See this OpenBSD Journal article regarding file flags and securelevel, including the links it references:
http://undeadly.org/cgi?action=artic...&mode=expanded

[Oko]

Originally Posted by jggimi

I agree with the majority of users (and developers) that not having comp*.tgz available does more harm than good -- in that admins who don't have maintenance tools available don't maintain properly. And an out-of-date system has more risks than an up-to-date one, if everything else is equal.

I agree 100% with you Jggimi. Now look the rest of my post. I wrote that if he wants to remove the compiler he has to have another machine which will be used for updating and maintenance of the production machine.

I also know where OpenBSD developers coming from. They want secure by default installation as their working assumption is that an average system admin is an idiot (which I cold-heartedly agree). In the light of that point of view they are correct that system with compiler is more secure than the one without it. But for BSDfun, you, and alike careful people theoretically speaking system without compiler is more secure. It is also true that is it far more costly (since you have to run a clone machine with exactly the same software, configuration and the compiler) and complicate to maintain such a computer.

For the record all my computers including firewalls do have compiler but if I run firewall for a large group of users I would run it without compiler.