Security Changes For Fedora 9

[Greg Metcalfe]

On Friday 04 January 2008 05:55:49 pm riley.marquis at tcsresearch.org wrote:
> In regards to the GCC lockdowns, it was my understanding that sometimes
> hackers use our own compilers against us by logging in as a normal user,
> using gcc to build their hacktools, and then using the built tools to
> compromise root.  Is this something that is no longer done?  Just curious.

A bit of data (a means of gathering your own, actually, in the form of a 
quick-and-dirty bash script) behind my opinion that it's not really 
worthwhile to restrict gcc, due to a plethora of interpreters. If there are 
any doubters, please read it over (including relevant man pages) and form 
your own conclusions about whether it's both useful, and safe to run.

I'd like to think that this is a dead issue, but I've not heard back from 
riley (who raised the point) saying that he buys into the explanation. So, to 
me, resolution is still in limbo. Much like a bug report, I'd be happier if 
all concerned parties agreed that it was closed.

Plus, I want to clear everyone's minds, while I create my own furor and 
flamage. I'm all on about noexec mount points, as per my first (original) 
post earlier today. That's a discussion which will no doubt end in tears. 
It's been held for years, but IMHO, it's becoming increasingly relevant.

#!/bin/bash
# Filename: int (interpreters)
# Tested on: Fedora 7, RHEL 5.0
# Warnings:
#   1) This isn't really the way to write bash. It's highly 
#   simplistic, on the assumption that some who may want to run 
#   it may have zero programming experience, but are (justifiably) 
#   hesitant to run code they've received through a mailing list.
#   This is my attempt to make it understandable, and more 
#   trustworthy, by reading a few man pages.
#   2) This doesn't consider all possible interpreters--only bash,
#   perl, and python. A typical Fedora install will have several
#   others. Even a minimal (as defined by installer) RHEL or RHAS 
#   will have others. Ex: awk, though not a shell, is interpreted.
#   There are also various restricted shells, such as escapes from
#   from vi, sendmail /usr/sbin/smrsh, etc., which have presented
#   problems in the past. /etc/shells isn't intended to list
#   these, and doesn't.

# hostname and kernel release
uname -nr

echo    # output a blank line as a spacer

# Eliminate self-referential Perl packages via grep. Paste 
# rpm -q --whatrequires perl | sort -u
# into a command line to see a list of Perl software that depends
# upon the basic Perl package.
rpm -q --whatrequires perl | grep -v '^perl-' | sort -u

echo    # repeat spacer

# Python packages aren't so self-referential, so no grep. But
# the list of admin tools many users will need is striking. To
# see that list, paste
# rpm -q --whatrequires python | grep 'system-config-' | sort -u
# into a command line.
rpm -q --whatrequires python | sort -u

echo    # repeat spacer

# Report software versions we're using
/bin/bash --version | head -n 1
/bin/uname --version | head -n 1
/bin/echo --version | head -n 1
/bin/rpm --version | head -n 1
/bin/grep --version | head -n 1
/bin/sort --version | head -n 1