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:54:10 +0200
On Tue, Aug 24, 2004 at 04:57:25PM +0200, Michel Arboi wrote:

Nessus has to run as root: it should be able to bind to low
"privileged" ports, to open raw sockets, to sniff network traffic...

True for standard Unix/Linux environment. However, if your OS can
grant chosen POSIX capabilities to a process or a user, you can run
nessusd under completely unprivilegged user provided he has
cap_net_raw, cap_net_bind_service, cap_net_broadcast and cap_net_admin
capabilities (the last one is probably not needed). We run Nessus (and
all other pen-test apps like Nmap, Hping2, tcpdump, Ethereal...) on
slightly hacked Linux kernel for years in that way and it works 100%

Martin Mačok
IT Security Consultant


P.S. If you are especially interested in privsep, you may be
interested in this message (search list archive for more):

Date: Wed, 19 Nov 2003 20:56:05 +0100 (MET)
From: Pavel Kankovsky <peak@argo.troja.mff.cuni.cz>
To: Nessus List <nessus@list.nessus.org>
Subject: Re: [Nessus] Permissions needed to install Nessus on Solaris...

[..]

One could split the server into a small "network services server" (nsserv)
running with high privileges and providing some kind of controlled access
to raw sockets and stuff (**), and the rest including client-server
communication, NASL interpreter, KB handling etc. This way, you could get
somewhat better protection than in a privileged non-root user approach
described above (an attacked subverting nessusd but not nsserv won't get
instant root and his control over the network communication would be
limited by the nsserv's policy (***)). But I am afraid most people here
have better things to work on.

[..]

(**) Well, in fact, Nessus already does something like that on FreeBSD
(due to the braindeadness of their BPF implementation), doesn't it?

(***) Such a policy might restrict the set of addresses one can talk to,
prohibit unlimited sniffing, prohibit messing with certain interfaces
(e.g. loopback) etc. Of course, the policy (or to be more precise, its
enforcer) must be kept as simple as possible or the whole point of nsserv
would be ruined.

[..]
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus

<Prev in Thread] Current Thread [Next in Thread>