Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build w/out Helper App #4

Closed
bobd992 opened this issue May 20, 2020 · 8 comments
Closed

Build w/out Helper App #4

bobd992 opened this issue May 20, 2020 · 8 comments

Comments

@bobd992
Copy link

bobd992 commented May 20, 2020

Is it possible to create a build of this app without the helper app? This would obviously mean having the user enter the password every time they change the setting for max battery, however it would now not have to run in the background all the time and it would theoretically be a more secure app and a complete uninstall would be possible after making the change. Most people would like to make the change and not have to worry about software lingering. Then if they need to change again in the future, they could just re-run and re-enter password. Something that doesn't require a full on install

I'd love to use it if so. I know this project is something you do in your spare time but you're doing a huge service to every mac user out there and a huge service to our environment by getting these batteries to last longer.

@davidwernhart
Copy link
Collaborator

Hi @bobd992!

Sadly, this is not possible. The only way to gain root access (or more precisely: make system calls that are only allowed for superusers) in GUI applications is using a privileged helper tool. This is actually the intended way to do such things by Apple. This is for security reasons, since the privileged helper tool can only do a limited number of things as root. You can see here that AlDente's helper tool is only able to read and write SMC keys. Because of this, malicious applications that try to exploit the tool can only do one thing with it and are not able to gain superuser privileges for the whole system. In addition to that, communication between the GUI app and the helper tool is bound to the signed Apple ID and encrypted, so malicious software that tries to hijack that the helper tool will have a very hard time in the first place.
The helper tool does not "run" at any time in the background, it is only consuming processing power when an application calls it. Since this is the only solution for GUI apps, I bet that the vast majority of users already have several applications with helper tools on their system, and most of them don't notice a difference.
The only way to achieve the functionality you request would incorporate starting the application with sudo from the terminal, which is not very elegant.

You can find more information about this topic here.

I hope this was helpful!
Best regards,
David

@bobd992
Copy link
Author

bobd992 commented May 20, 2020 via email

@davidwernhart
Copy link
Collaborator

davidwernhart commented May 22, 2020

Thank you for making me aware of this project!
In my opinion, it looks very promising and ambitious.

I looked into how this tool achieves SMC write without a helper tool. As I stated previously, the only alternative to a helper tool is starting a script with sudo. Turns out, BatteryStatusShow does exactly this. In this source file on line 219, you can see that they use the NSAppleScript call to emulate terminal input and start a second script with sudo to change SMC values.
Although this does not seem as an acute potential security thread to me, it is definitly not the most elegant solution. Like I already said, using a privileged helper is actually the preferred way to do such things and Apple specifically employed this system because of it's increased security. Another great explanation on why this makes sense can be found here. Because of this, I will stick with the privileged helper approach for now. But I am going to reopen this issue and consider switching to the NSAppleScript-Approach if enough users request it.

Thank you for your great feedback and best regards,
David

@davidwernhart davidwernhart reopened this May 22, 2020
@bobd992
Copy link
Author

bobd992 commented May 25, 2020 via email

@davidwernhart
Copy link
Collaborator

Hi @bobd992!
To be honest, I am having a hard time deciphering your message.
What do you mean with notarized and which automated system are you talking about?

Best regards,
David

@bobd992
Copy link
Author

bobd992 commented May 26, 2020 via email

@davidwernhart
Copy link
Collaborator

Thank you for that insight @bobd992 !

I genuinely did not know about notarization beforehand.
Sadly, it seems like an Apple Developer License is required to notarize an application. The license costs 99$ annually, which I cannot afford right now for this open source project. I updated the instructions in the readme to circumvent this issue.

Best regards,
David

@bobd992
Copy link
Author

bobd992 commented Jun 4, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants