Hi, thanks for the work on this project!
I had a small security concern and a suggestion. Right now ThinkUtils uses pkexec with bash and changes permissions on some /sys files. Would you consider a simpler flow where the app lets users stage changes, then on Apply it runs a small dedicated helper with one elevation prompt to write the needed values? No world-writable /sys changes, no passwordless rules, and no temp bash scripts. The helper could be a tiny binary with input validation, run via a narrow polkit action tied to its path. Or it could be done by obtaining sudo in different ways by running a single command on-demand, if it makes sense.
I think this would keep the UX good - one prompt when clicking Apply - and reduce risk. It might also make packaging easier since we could drop the broad org.freedesktop.policykit.exec policy and the extra scripts. #3 for reference.
I am not a security expert, so apologies if I misunderstood parts of the design. Does this direction sound reasonable? Any constraints I should be aware of or a different approach you would prefer? Happy to help test or iterate and help with code as well but wanted to see what you think first! :)
Thanks!
Hi, thanks for the work on this project!
I had a small security concern and a suggestion. Right now ThinkUtils uses pkexec with bash and changes permissions on some
/sysfiles. Would you consider a simpler flow where the app lets users stage changes, then on Apply it runs a small dedicated helper with one elevation prompt to write the needed values? No world-writable /sys changes, no passwordless rules, and no temp bash scripts. The helper could be a tiny binary with input validation, run via a narrow polkit action tied to its path. Or it could be done by obtaining sudo in different ways by running a single command on-demand, if it makes sense.I think this would keep the UX good - one prompt when clicking Apply - and reduce risk. It might also make packaging easier since we could drop the broad org.freedesktop.policykit.exec policy and the extra scripts. #3 for reference.
I am not a security expert, so apologies if I misunderstood parts of the design. Does this direction sound reasonable? Any constraints I should be aware of or a different approach you would prefer? Happy to help test or iterate and help with code as well but wanted to see what you think first! :)
Thanks!