Feature Request: password protected access to Rules-List

[Sonic-79]

Password protected access to Rules-List. I'd like to have LuLu on our Users MacBooks, But if the User can change the Rules without the need for an administrative Password he might just add "all programs any port allow" and Lulu ist more or less disabled.

[mdjunior]

There are workarounds for this, but securing rule files is a bit tricky. I think you'd like to do an enterprise use of Lulu and that's possible, but that rule editing part is really complex.

I'll detail one approach here, but keep in mind that there are unwanted behaviors as side effects.

1. You have to configure a deny rule in Lulu so that new accesses don't generate alerts. Just create a rule where the path is * with the block action.
2. You need to change the settings to passive mode. As you have a rule that denies everything, alerts will no longer be displayed because if there is no specific rule, traffic will be denied.
3. You can disable the Lulu icon from the menu bar to not encourage the user to try to modify the rules or finish Lulu. Here I'm just talking in terms of incentives... there's a whole philosophy around Honest Security and communicating tool behavior that you can take into account.
4. You can mark the rules file as system immutable (you can do the same with the preferences file). By doing this, the Lulu extension will not be able to write to it. A very undesirable effect here is that the Lulu code does infinite retries (check here). Therefore, if a user tries to edit the rules through the interface, the system may become unusable, have a disk full of logs and generate other types of problems.

[Sonic-79]

Thank you for your answer. In the meanwhile, I found a solution using pfctl that can only be altered if you have admin privileges. That was a bit tricky aswell ;-)

Am So., 28. Mai 2023 um 23:44 Uhr schrieb Manoel Domingues Junior < @.***>:

There are workarounds for this, but securing rule files is a bit tricky. I think you'd like to do an enterprise use of Lulu and that's possible, but that rule editing part is really complex.

I'll detail one approach here, but keep in mind that there are unwanted behaviors as side effects.

1. You have to configure a deny rule in Lulu so that new accesses don't generate alerts. Just create a rule where the path is * with the block action.
2. You need to change the settings to passive mode. As you have a rule that denies everything, alerts will no longer be displayed because if there is no specific rule, traffic will be denied.
3. You can disable the Lulu icon from the menu bar to not encourage the user to try to modify the rules or finish Lulu. Here I'm just talking in terms of incentives... there's a whole philosophy around Honest Security https://honest.security/ and communicating tool behavior that you can take into account.
4. You can mark the rules file as system immutable (you can do the same with the preferences file). By doing this, the Lulu extension will not be able to write to it. A very undesirable effect here is that the Lulu code does infinite retries (check here https://github.com/objective-see/LuLu/blob/50478cdea08e2e6c1fae935890938eb173aa146b/LuLu/Extension/Rules.m#L930). Therefore, if a user tries to edit the rules through the interface, the system may become unusable, have a disk full of logs and generate other types of problems.

— Reply to this email directly, view it on GitHub https://github.com/objective-see/LuLu/issues/517#issuecomment-1566274191, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3E54HPDCHK7VGPRHF2W37LXIPBNTANCNFSM6AAAAAAUMS663M . You are receiving this because you authored the thread.Message ID: @.***>