[Debian] Removing Compiler

sspiro · 12-29-2010, 08:32 AM

I want to remove to help reduce vulnerabilities..

I'm somewhat new to linux, and have a good functioning knowledge, but dont want to do something stupid, so i'd rather asking a stupid question.

would 'apt-get autoremove make' be the proper command? It wants to remove about 30 or so packages. I don't want to lose anything i might need to run apache2 and similar packages (self-configured web server). Running Lenny.

Thanks..!

AlucardZero · 12-29-2010, 08:35 AM

Can you post the list of all packages it wants to remove? You really want to remove gcc and g++.

Also, "apt-cache show packagename" or http://www.debian.org/distrib/packages will give you package descriptions.

sspiro · 12-29-2010, 08:59 AM

Quote:

Originally Posted by AlucardZero

Can you post the list of all packages it wants to remove? You really want to remove gcc and g++.

Also, "apt-cache show packagename" or http://www.debian.org/distrib/packages will give you package descriptions.

Code:

The following packages were automatically installed and are no longer required:
  libstdc++6-4.3-dev libuser-identity-perl intltool-debian libmime-types-perl
  g++-4.3 po-debconf libfile-remove-perl g++ libmail-sendmail-perl gettext
  libobject-realize-later-perl html2text libmail-box-perl
The following packages will be REMOVED:
  build-essential debhelper dpkg-dev g++ g++-4.3 gettext html2text
  intltool-debian libfile-remove-perl libmail-box-perl libmail-sendmail-perl
  libmime-types-perl libobject-realize-later-perl libstdc++6-4.3-dev
  libuser-identity-perl make po-debconf
0 upgraded, 0 newly installed, 17 to remove and 0 not upgraded.
After this operation, 34.9MB disk space will be freed.

Reuti · 12-30-2010, 04:55 AM

Anyone can install a compiler in their own home. It's not necessary to have it in /usr/bin. So IMHO removing a compiler won't change the vulnerability.

sspiro · 12-30-2010, 06:28 AM

Quote:

Originally Posted by Reuti

Anyone can install a compiler in their own home. It's not necessary to have it in /usr/bin. So IMHO removing a compiler won't change the vulnerability.

I only have one user, and its me.. or does that not matter.

Reuti · 12-30-2010, 06:40 AM

So, where is the vulnerability? When a hacker gains access to your machine (using your account) he can install a compiler on his own. A compiler laying around on the disk won't do any harm. I would see it more in the context of space, e.g. you have a netbook with a small SSD and want to save some space, then I would remove it. Otherwise it doesn't matter.

sspiro · 12-30-2010, 07:09 AM

Great info, thank you..

unixfool · 12-30-2010, 07:56 AM

Great response, Reuti. Your thoughts on that mimic my own. What's pretty wild is that I was reading over some NIST standards 5 years ago and remember reading a recommendation that was similar to what the OP was trying to do. The recommendation was to remove any compilers from the system.

People tend to forget that once a machine is cracked and root access is gained, anything that isn't already installed can be added by the malicious user. Not only that, but a cracker can also bring his own binaries. So, if the system is cracked, the cracker can either reinstall the removed compiler(s) or introduce binaries that he/she compiled before ripping into the system. The latter scenario is probably the better option for the cracker, as compiling software can sometimes be rather 'noisy'. It's more difficult to be stealthy if you've to compile, especially if the compiling registers as a system resource hit that is substantial enough to attract system admin attention. A cracker that gains system access only to begin to noisily compile software probably isn't a good cracker. The better effort would be to continually monitor network entry and exit points and harden those points to the maximum extent.

sspiro · 12-30-2010, 08:22 AM

Thanks guys, great input. Really appreciate it. I'll continue to research locking down this lenny server and see what happens..