Hi, James, Thank you very much for your comments, please see in line. > 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?) > It definitely does not read from kernel memory directly.
All the data comes from libpcap and it tries to handle it in real time, as you said. For me, 64-bit /usr/bin/64/snort exists because snort also is able to deliver 64bit plugin libraries(/usr/lib/64/snort_preprocessors/*), I've asked developers about difference between these 64bit and 32bit plugin libraries. The following is their answers. #################################### ..... There isn't anything specific in Snort that is relying on 32 vs 64 bit. Pointer sizes would change. The only real restriction is that the Snort binary and the shared libraries must be the same (64bit or 32bit), otherwise data structure sizes will likely cause a core or other bus error. ..... #################################### And from function point of view, through my testing,there is no difference between 64bit and 32bit. But on 64bit machines, it might be required to use 64bit plugin libraries, so the 64bit /usr/bin/64/snort is delivered. In my test results, there is no difference between 64bit and 32bit. > 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. > I usually run the snort in bash by hands, not in daemon mode. However, I could not say most of administrator may run it in daemon mode. It definitely can support daemon, The following is an example to run snort in daemon mode. # snort -D -d -N -c /etc/snort.conf It is possible user can run the command as their own, but if there is no enough permission, the command line will exit with fail message. > 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. > So far, it mainly depends on libpcap.so and libpcre.so which has been ported into OpenSolaris as SUNWlibpcap and SUNWpcre packages. > 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. > Right. > Do those come from RBAC, or is the user expected to use "sudo"? > "sudo" could work. Thanks Jason
