Bug #361
closed
AF_PACKET fails to initialize when running with limited privileges
Added by Doug Burks about 13 years ago.
Updated about 13 years ago.
Description
If I run Suricata with AF_PACKET as shown below, everything is fine:
suricata -c /etc/suricata/suricata.yaml --af-packet=eth0
However, if I tell Suricata to drop to a non-root user like this:
suricata --user sguil --group sguil -c /etc/suricata/suricata.yaml --af-packet=eth0
it drops the capabilities and then AF_PACKET fails to initialize.
Should Suricata initialize AF_PACKET first, and then drop capabilities?
Files
- Target version changed from 1.1beta3 to 1.1rc1
- Estimated time set to 4.00 h
I think the device reopening if it goes up and down won't work either after dropping privs. So we better handle that gracefully :)
Agreed on this point. Will have to find something clever there.
- Status changed from New to Assigned
- Priority changed from Normal to High
AF_PACKET behaves like pcap from a capability point of view. The attached patch just translate this in code.
- Target version changed from 1.1rc1 to 1.2beta1
Applied, thanks Eric!
Leaving the ticket open for tracking the device reopening when privs have been dropped.
Good idea. It should work as we are not dropping the raw socket capability but nothing is better than a real test!
- % Done changed from 90 to 100
Check done. This is working fine.
- Status changed from Assigned to Closed
- Target version changed from 1.2beta1 to 1.1rc1
Cool, thanks for checking.
Also available in: Atom
PDF