Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Privelege separation |
|---|---|
| Date: | Tue, 24 Aug 2004 22:26:29 +0200 |
On Tue Aug 24 2004 at 17:49, eric wrote:
Wow, uh. This comes from a security vendor?
No, this comes from a security *giver*. Believe it or not, I never got a cent for what I did for this project. I did not ask either. Consider me as a fucking communist if this pleases you.
The whole idea behind privsep
Thank you, I know what privsep is. As you seem to question my competences in computer security, I will allow myself to question yours. By the way, I consider that your message was insulting. Don't excuse yourself, it's too late, I have too much Mediterranean blood.
is that the *least* amount of code runs as root.
Unfortunately, this is not a silver bullet for Nessus. You know... No you don't know, do you? In fact, there is no such thing as "absolute" security. And applying general principles is good as long as it does not hurt... other general principles. For example, complexity is the enemy of security. Splitting Nessus into several parts will increase the code complexity and the number of bugs. And also, general principles are not worth a good risk analysis. I have already said what I considered the main risks about Nessus. The soft point is the OpenSSL library, because it is the biggest and more complex part of code. Protect the client / server communication with TCP wrappers, and you'll solve most of the problems. If the OpenSSL client code is vulnerable to some "reverse attack", the bad guy could take control of the nessusd server. Whether he is root or not does not matter: he can nuke your whole network. Privsep won't help.
OpenBSD has done it for tcpdump, syslogd, etc.
So what? You want to do it for Nessus? Submit a patch and stop pissing me off. This is _free_ and _open_ software. You are allowed to code, to test, to suggest new ideas, not to insult me.
Perhaps this would protect nessus itself from an overflow that might pop up in the future
One of the main goal of NASL is to insure that test scripts run inside a kind of sandbox. As far as we know, there is no reverse buffer overflow.
Then again, it's your product! :-)
In a way, it's everybody's product. GPL.
and clearly it needs to be protected by other mechanisms.
No. Not clearly. _______________________________________________ Nessus mailing list Nessus@list.nessus.org http://mail.nessus.org/mailman/listinfo/nessus
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Nessus Option?, IndianZ |
|---|---|
| Next by Date: | Re: Privelege separation, Martin Mačok |
| Previous by Thread: | Re: Privelege separation, eric |
| Next by Thread: | Re: Privelege separation, eric |
| Indexes: | [Date] [Thread] [Top] [All Lists] |