Privelege separation

Michel Arboi mikhail at nessus.org
Tue Aug 24 16:26:29 EDT 2004


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.




More information about the Nessus mailing list