James Walker writes: > /usr/bin/64/snort Uncommitted 64-bit Command
What's this about? What does the utility do that actually requires 64-bit operation? (Does it read from kernel memory directly?) Is snort ordinarily used in daemon mode? If so, shouldn't there be an SMF configuration for it? Otherwise, users are forced to roll their own, and the project seems incomplete. The files that snort consumes have no stability at all. It's designed to read from system log files, and we simply place no controls on those at all. The messages it needs in order to do its analysis may change incompatibly, at any time, and without notice. I certainly understand the popularity of snort. It partially fills an important functional gap (simplifying administration by sifting through system data, albeit only portions of the security aspects). But given that it's designed to rely on things that are explicitly not designed to be programmatic interfaces in OpenSolaris, it's unclear to me how to the ARC could ever endorse it. It may break, and there's nothing that any ARC review could do to avoid that prospect. I suspect we'll need to derail and review it formally. Joep Vesseur writes: > > If it's not suid (as ping is), I presume that snort needs something > > like net_observibility or net_raw_access to run properly. How does > > it get that or any other privileges it may need? > > What Rights Profile (and exec_attr(4) properties are required)? > > sort monitors logfiles; if it can read those, there's no need for additional > privileges. Snort does far more than just read files. It links to libpcap and can snoop on network interfaces in real time. To do *that*, it will require elevated privileges. Do those come from RBAC, or is the user expected to use "sudo"? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
