Mailing List Archive

Basic questions regarding nessus implementation
I've just started trying to use nessus, and I have a few basic ques-
tions about the implementation, if that's alright.

First, I'd like to know why the various supporting libraries are built,
by default, as shared libraries. Is there really any likelihood at all
that any of these libraries are going to be used by multiple independent
and different executables? If not, then why bother with all of the
shared library overhead? That seems like rather pointless complexity
and overhead to me.

Second, I'd like to understand why the standard (UNIX) installation
instructions found at:

http://www.nessus.org/install.html

insist that everything, including the support libraries, must be
installed while operating as root, and why the daemon cannot be run
by an ordinary end user.

I can't help but say that I find it both extraordinary and perplexing
that a tool designed primarily for use by security-concious administrators
seems to require root privledges without even offering _any_ explanation
as to why this might be the case.

Do you folks who have worked on developing this thing really expect
paranoid admins to both (a) install this great big mass of suspect
foreign code as root and to (b) run it as root for no other reason than
because that is what the install instructions say to do?

If so, I'd like to suggest that this is a rather unreasonable position.

If this program really requires root privs, then fine. In that case, the
install instructions should specify exactly what root privs are required
and why. (Just saying ``trust us'' doesn't really cut it.)

But I strongly suspect that there is in fact little if any need for root
privs in order to perform the majority of the kinds of `over-the-wire'
security tests (of other systems) that the Nessus package performs, so
I really would like to know where the requirement for root is coming from.

If a program such as nmap can run without any root privs at all then why
does Nessus... which seems to concentrate on tests that require little or
no access to raw sockets... need such privledges?

This seems pretty mysterious and inexplicable to me.

Even if Nessus does implement some kinds of tests that require access to
raw sockets, couldn't a verison of Nessus be made available that would only
perform all of the OTHER tests (that do not require such access) and
couldn't that be installed and run from a non-root account?


Regards,
rfg


P.S. I for one have learned tp be _very_ paranoid. And there's no way in
hell that I'm going to run this thing as root unless and until I know _why_
it must be run as root.

P.P.S. Isn't it customary... _especially_ for `sensitive' programs, for ex-
ample those that will be run with elevated privledges... to be distributed
along with some sort of a associated cryptographic signature file which
can be used to insure that the distribution files themselves have not been
corrupted, either accidentally or deliberately?

I don't recall seeing any such signature files for any of the four .tar.gz
files of the distribution in the FTP directory where I fetched them from.
Did I just overlook them, or were there really none in there?
Re: Basic questions regarding nessus implementation [ In reply to ]
(I did not reply to that one in the first place. I'm really not
reactive)

On Sun, Dec 09, 2001 at 09:13:09PM -0800, Ronald F. Guilmette wrote:

> I've just started trying to use nessus, and I have a few basic ques-
> tions about the implementation, if that's alright.
>
> First, I'd like to know why the various supporting libraries are built,
> by default, as shared libraries. Is there really any likelihood at all
> that any of these libraries are going to be used by multiple independent
> and different executables?

Apart from the fact that there are three executables sharing these
libraries (nessusd, nessus and nasl), there's a technical reason :
nessusd handles two kinds of plugins : .nasl and .nes. The .nes
plugins are actually compiled C code, and they are themselves shared
libraries, loaded on the fly using dlopen().

Now, it turns out that they use functions in libnessus & al, and the
behavior changes from one OS version to another (actually, it changes
from one version of ld to another), and with some OSes, the .nes plugins
need to be linked with the library they use.

> insist that everything, including the support libraries, must be
> installed while operating as root, and why the daemon cannot be run
> by an ordinary end user.

Ok, forgive my lazyness and the time it took me to reply to this, this
issue has been beaten to death on nessus@list.nessus.org now.

Just a note :

> I don't recall seeing any such signature files for any of the four .tar.gz
> files of the distribution in the FTP directory where I fetched them from.
> Did I just overlook them, or were there really none in there?

That's my current policy. I'm not garanteeing anything (read the
definition of the GPL), not even the fact that you downloaded the right
files. That may or may not change though, I still don't know.

-- Renaud
Re: Basic questions regarding nessus implementation [ In reply to ]
On Thu, 13 Dec 2001, Renaud Deraison wrote:

> That's my current policy. I'm not garanteeing anything (read the
> definition of the GPL), not even the fact that you downloaded the right
> files. That may or may not change though, I still don't know.

I am not saying you should start providing a guarantee of any sort.
Anyway, there have been attempts to distribute trojanized versions of
other software in the past. I guess it is better to address this sort
of attack before more people discover its potential (*).

(*) My crystal ball says we'll see malware hijacking connections and
infecting transmitted files in less than two years.

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."