Welcome to the most active Linux Forum on the web.
Go Back > Forums > Linux Forums > Linux - Security
User Name
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.


  Search this Thread
Old 09-05-2003, 08:01 AM   #1
Registered: Aug 2003
Distribution: Red Hat 9
Posts: 76

Rep: Reputation: 15
security issues with compilers?

It was mentioned that having compilers on my RH Linux box could be a security issue. I had to install C compilers just while I was building but I will be removing those now that I am finished.

However, I need to keep the java compiler on the system.... I installed it as root, but it shows owner as root:bin.

Is this unsafe to have on my system? If its ok, should I change owner?

Old 09-06-2003, 06:23 AM   #2
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600
The reason compilers should be removed from a server is they can be abused, an excellent example is the Apache Slapper worm.

If removing a compiler is not an option, then you have to look into I. restricting access to it, and II. restrict the compiler itself from using/accessing resources that (could) pose a threat to system safety or the network. Finally you could III. chroot the package. Mind you I haven't looked into JIT compiler related exploits, but the basics still apply.

If you need to keep Java around, this is probably for the benefit of a server (or server application). To determine the feasibility of restrictions you should check if your server (or server application) and Java need root privileges.

Think of privileged users not as names but as placeholders, as a containers, for capability sets. One way to see what capabilities your system uses would be to check Lcap.
For instance on a (production) where you haven't compiled modules into a monolithical kernel SYS_CAP_MOD can be taken away with lcap. This denies anyone (including root) at least one method of loading modules (a reboot fixes that so set lcap after all initscripts have run). Of course this is just one example of capabilities, and may not be appropriate for this example, because Lcap doesn't guard against apps inheriting capabilities and (re)using them but takes them away on a system-wide scale. On one part managing this needs proper coding on the application part, the rest you can manage using Grsecurity/LIDS.

I. Restricting access to the binary chowning it to a lesser privileged user and setting proper access rights is the simplest step you can take, but it won't "protect" you against mischief in the case the server app or the user gets compromised like in the Apache case, it only protects against other users accessing it.

If for instance you run Jakarta as non-root (meaning it drops privs after binding to a server port), and Java doesn't need root privileges (use network sockets, bind to privileged port, access root-owned files etc etc) to work with, then running the whole package under a lesser-privileged user account lessens the risks of wider system muckage when Something Breaks. Remember this also goes for any files the package needs to access (improper access rights and permissions).

II. To be on the safe side you'd have to restrict the itself binary from harming system and network as well. For that I would default to using the Grsecurity or LIDS kernel patches. They both provide means of applying ACL's to restrict apps movements, manage capabilities on a per-application basis and allow auditing.

This means in case of our example Jakarta, that even if run as root you still have means to restrict the whole package from accessing parts of the filesystem, system resources and network resources, and take away capabilities the process doesn't need to survive. Smallprint warning: OF COURSE THIS DOESNT MEAN YOU SHOULD ACTUALLY RUN STUPH AS ROOT UNLESS YOU HAVE COMPELLING REASONS TO DO SO. AND NO. LAZINESS AIN'T ONE OF THEM. Heh.

III. You could also try to chroot Java, but then you probably would have to chroot everything the application/user encompasses else a lot will definately break... It isn't that hard but tricky at times, there are some docs on chrooting in the 1st sticky thread of this board (see the index), but chances could be you still end up having to allow access to devices inside the jail that could weaken it.
Would make for a nice exercise tho.

// I apologize for the detailed answer, but I think it is best determine yourself on basis of what I wrote and what's practical what to do, rather than me shipping a yes or no type of answer. Research and experiment, learn from it and propagate your knowledge.
// I also have to get ready for finalizing the first part of our LQ Newbie Security Tutorial, so answering questions like this helps *me*focus as well...
// Finally, don't take my word for it. Looking for a second opinion is always a good choice.

Last edited by unSpawn; 09-06-2003 at 06:26 AM.
Old 09-11-2003, 12:39 PM   #3
Registered: Aug 2003
Distribution: Red Hat 9
Posts: 76

Original Poster
Rep: Reputation: 15
No need to apologize for the detailed answer - it was great, and very kind of you to take the time.

When Jakarta has been started the processes are run as 'tomcat' - a non-priveleged user.

I have read a little of chrooting, and I am interested in looking further into that.

Thanks again for your post.


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
KDE/security issues sc_3007 Linux - General 6 05-27-2005 02:47 PM
Security Issues? Xon Linux - Security 3 10-04-2004 11:45 PM
security issues with a RH 9.2 merlin Linux - Security 1 02-24-2004 04:13 PM
Solaris 5.1 security issues hopbalt Solaris / OpenSolaris 6 08-04-2003 05:31 AM
Bind and security issues jchristman Linux - Networking 0 07-16-2003 08:36 AM > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 03:57 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration