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: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> |
|---|---|---|
| ||
| Previous by Date: | Re: Privelege separation, Michel Arboi |
|---|---|
| Next by Date: | Re: auto_enable_dependencies doesn't seem to work correctly for 2.0.12, Jason Haar |
| Previous by Thread: | Re: Privelege separation, eric |
| Next by Thread: | RE: Privelege separation, McKechnie, Grant (Contractor) |
| Indexes: | [Date] [Thread] [Top] [All Lists] |