[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should gcc be usable by world ?



> Hi:
>

Not to troll, but FreeBSD (or Linux for that matter) shouldn't have this
problem. FreeBSD supports jail(8)s. So does Linux (grsecurity comes to
mind, so does UML, although UML may be less desirable due to size...). I
highly recommend running apache in a jail(8) and only other things you
need. This allows for one to run a machine as more than a web server, but
still practice good security (e.g. don't run compilers on production
system). Your jail only needs to have apache, the libraries apache
requires, and your content. You content could even be placed inside
another jail and served via ldap or sql and done via virtual networking
but that may be too much Iwork. Jails do not add significant overhead and
are standard in all recent versions of FreeBSD. Check into it.

>  I see that gcc, g++, and other tools are usable by world (others). I was
> wondering if that is a bad idea as I read here:
> http://www.itworld.com/nl/lnx_sec/09242002/pf_index.html
> that the slapper worm used gcc to compile it's exploit.
>  Excerpt: The worm requires gcc to compile the .bugtraq.c file. ....
>

That really depends on how much you trust your users. I'd say don't allow
local users anyway and put them inside a fully stocked world from /usr/src
via jail and leave them there. In fact, I don't see a good reason not to.
That allows you to disallow all non-system accounts (besides yours which
you should need to su to root) and further secure the system. jail(8) is
your friend.

bja

> Is it a good idea to change the permisions on the gcc tools to 750 ? I
> looked through the FreeBSD Handbook and could find no advice on this
> matter. Also, are there other tools that should not be available like
> strace? How can I find out which ones are potentially
> exploitable?
>
>                                Kind regards,
>                                Jonathan
>
> -
> To unsubscribe, send email to majordomo@silug.org with
> "unsubscribe silug-discuss" in the body.
>


-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.