search

AppHouseKitchen / AlDente-Charge-Limiter

Menubar Tool to set Charge Limits and Prolong Battery Lifespan
https://apphousekitchen.com/
Other
7.85k stars 290 forks source link

Build w/out Helper App #4

Closed bobd992 closed 3 years ago

bobd992 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

You are excellent, thanks so much for the explanations!!

This was from a macrumors post that made me question this:

We create a open source APP view of Mac/IOS Battery Information: https://github.com/sicreative/BatteryStatusShow As 1.5.1 new version we added the function some as AlDente to adjust the change level, Theory is some, as our APP without use any helper which will run in background, instead we require every time change of this value need input admin passwd, Please feel free to give any feedback.

On Wed, May 20, 2020 at 12:15 PM davidwernhart notifications@github.com wrote:

Hi @bobd992 https://github.com/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 https://github.com/davidwernhart/AlDente/blob/master/com.davidwernhart.Helper/HelperTool.swift 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. https://developer.apple.com/documentation/servicemanagement/1431078-smjobbless?language=objc

I hope this was helpful! Best regards, David

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/davidwernhart/AlDente/issues/4#issuecomment-631576731, or unsubscribe https://github.com/notifications/unsubscribe-auth/APRPUMODGNLZO663ININDTTRSP63FANCNFSM4NF4OMUA .

davidwernhart commented 4 years ago

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

bobd992 commented 4 years ago

Thank you! After reading more, I thought to give it shot because I really want to protect my battery... but I'm wondering - is your software not notarized because the automated system would deny it because it's writing to the SMC or some other reason?

On Fri, May 22, 2020 at 5:21 PM davidwernhart notifications@github.com wrote:

Reopened #4 https://github.com/davidwernhart/AlDente/issues/4.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/davidwernhart/AlDente/issues/4#event-3366217298, or unsubscribe https://github.com/notifications/unsubscribe-auth/APRPUMOWB2TQDG7ZOMZAX3TRS3UETANCNFSM4NF4OMUA .

davidwernhart commented 4 years ago

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 commented 4 years ago

When launching your app for the first time, this is the message I get:

AlDente can't be opened because Apple cannot check it for malicious software. This software needs to be updated. Contact the developer for more information.

Upon further investigation, it seems like the app needs to be notarized by apple for this to not happen. https://dev.to/nimit95/how-to-fix-app-failures-on-mac-os-catalina-notarization-oc8

On Tue, May 26, 2020 at 10:48 AM davidwernhart notifications@github.com wrote:

Hi @bobd992 https://github.com/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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/davidwernhart/AlDente/issues/4#issuecomment-634072840, or unsubscribe https://github.com/notifications/unsubscribe-auth/APRPUMOE3XWMU4FNTH4HJGTRTPJEPANCNFSM4NF4OMUA .

davidwernhart commented 4 years ago

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 commented 4 years ago

Understood. I’ve actually been using it and did more homework, seems like everything makes sense with your approach and I really like it! It works beautifully. Thanks again for creating this tool.

On Thu, Jun 4, 2020 at 10:54 AM davidwernhart notifications@github.com wrote:

Thank you for that insight @bobd992 https://github.com/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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/davidwernhart/AlDente/issues/4#issuecomment-638902818, or unsubscribe https://github.com/notifications/unsubscribe-auth/APRPUMPNOB3BRCJQ6ZRJP43RU6YSZANCNFSM4NF4OMUA .