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.




Network Security Nessus-Users
[Top] [All Lists]

Re: Privelege separation

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>