Bug #361
closedAF_PACKET fails to initialize when running with limited privileges
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
Updated by Eric Leblond over 12 years ago
- Target version changed from 1.1beta3 to 1.1rc1
- Estimated time set to 4.00 h
Updated by Victor Julien over 12 years ago
I think the device reopening if it goes up and down won't work either after dropping privs. So we better handle that gracefully :)
Updated by Eric Leblond over 12 years ago
Agreed on this point. Will have to find something clever there.
Updated by Victor Julien over 12 years ago
- Status changed from New to Assigned
- Priority changed from Normal to High
Updated by Eric Leblond over 12 years ago
- File 0001-Add-AF_PACKET-to-capability-system.patch 0001-Add-AF_PACKET-to-capability-system.patch added
- % Done changed from 0 to 90
AF_PACKET behaves like pcap from a capability point of view. The attached patch just translate this in code.
Updated by Victor Julien over 12 years ago
- 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.
Updated by Eric Leblond over 12 years ago
Good idea. It should work as we are not dropping the raw socket capability but nothing is better than a real test!
Updated by Eric Leblond over 12 years ago
- % Done changed from 90 to 100
Check done. This is working fine.
Updated by Victor Julien over 12 years ago
- Status changed from Assigned to Closed
- Target version changed from 1.2beta1 to 1.1rc1
Cool, thanks for checking.