Re: [PATCH] lldpad_t tries to automatically disable LLDP on network card but is blocked

Chris PeBenito <[email protected]> Mon, 17 Mar 2025 14:17:49 -0400
Newsgroups org.kernel.vger.selinux-refpolicy
Message-ID <[email protected]>
On 3/17/2025 6:10 AM, bmare wrote:
> Hello,
> 
> Your fix seems great to me.
> 
> I'm just wondering the use of "kernel_dontaudit_write_debugfs" 
> interface. It would be simpler to audit this error, so the end user 
> could see the right boolean to enable with the "audit2allow" command 
> (for example), which is quit helpful. He might quickly notice that the 
> error originates from SELinux and takes the appropriate action to fix 
> the problem.
> 
> My understanding of the lldp daemon is that it won't try to write to 
> debugfs if it's not in the case of the i40e driver, which mean the error 
> message should only be displayed if access to debugfs is worth having. 

That's good to know.  I dropped that part from the patch.


> On 13/03/2025 20:18, Chris PeBenito wrote:
>> On 3/13/2025 11:32 AM, Chris PeBenito wrote:
>>> On 3/13/2025 10:29 AM, bmare wrote:
>>>> When running lldp daemon on a server, you can have the following 
>>>> error message:
>>>>
>>>> """
>>>>
>>>> i40e driver detected for ens10f1, disabling LLDP in firmware
>>>>
>>>> cannot open /sys/kernel/debug/i40e/0000:0f:00.1/command to disable 
>>>> LLDP in firmware for ens10f1: Permission Denied
>>>>
>>>> """
>>>>
>>>> In the selinux logs, you can see lldp is trying to open a specific 
>>>> file and write to it
>>>>
>>>> """
>>>>
>>>> avc:  denied  { write } for  pid=2264219 comm="lldpd" name="command" 
>>>> dev="debugfs" ino=109
>>>>
>>>> avc:  denied  { open } for  pid=2264219 comm="lldpd" path="/sys/ 
>>>> kernel/ debug/i40e/0000:0f:00.0/command"
>>>>
>>>> """
>>>>
>>>>  > LLDP needs the following authorization: "allow lldpad_t 
>>>> debugfs_t:file { open write };"
>>>>
>>>> In fact, if you are trying to configure and run a local lldp daemon, 
>>>> you don't wan't the network card to run LLDP as well, both will 
>>>> conflicts, and lldp daemon is probably configured to give better 
>>>> informations for network administrators (hostname of the server for 
>>>> example). It could be a good idea to (optionally ?) allow lldp 
>>>> daemon to automatically unconfigure LLDP on network cards.
>>>>
>>>> I've tried to create a patch doing this (create a boolean, add 
>>>> permissions to read and write do debugfs files). It could be 
>>>> simplified to allow writing to debugfs without a boolean, but I 
>>>> feels like it could be a security issue and an optional boolean 
>>>> enabled only if needed is a better option.
>>>
>>> I definitely agree that the debugfs use is problematic and we would 
>>> want this to be conditional in the policy.
>>>
>>> The fact that there is no standard interface for doing this, such as 
>>> in sysfs, seems like an issue in the driver(s) too. Configuring a 
>>> device shouldn't go through debugfs AFAIK.
>>>
>>>
>>>> --- policy/modules/services/lldpad.te.old    2025-03-13 
>>>> 15:16:38.982728194 +0100
>>>> +++ policy/modules/services/lldpad.te.new    2025-03-13 
>>>> 15:17:03.111728930 +0100
>>>> @@ -4,6 +4,16 @@
>>>>  #
>>>>  # Declarations
>>>>  #
>>>> +## <desc>
>>>> +##      <p>
>>>> +##      Allow lldp daemonn to write
>>>> +##      to debugfs.
>>>> +##      Permit lldp to automatically
>>>> +##      disable LLDP on physical
>>>> +##      network card
>>>> +##      </p>
>>>> +## </desc>
>>>> +gen_tunable(allow_lldpad_write_debugfs, false)
>>>>
>>>>  type lldpad_t;
>>>>  type lldpad_exec_t;
>>>> @@ -60,3 +70,8 @@
>>>>  optional_policy(`
>>>>      fcoe_dgram_send_fcoemon(lldpad_t)
>>>>  ')
>>>> +
>>>> +tunable_policy(`allow_lldpad_write_debugfs',`
>>>> +        kernel_manage_debugfs(lldpad_t)
>>>
>>> Based on the logs you provided, this is excessive access, so I'd make 
>>> a new kernel_write_debugfs() interface with only write access.
>>
>> I posted a revised version of this as a PR here: https://github.com/ 
>> SELinuxProject/refpolicy/pull/873
>>
>> Let me know if there are any issues -- here on the ML or as comments 
>> in GitHub.



-- 
Chris PeBenito