Re: Looking for opinions on authorization frameworks for Pallet
Hey Joshua, Sorry to get back to you late, I was with family this weekend. Anyhow, from how I understand it, the application must be started internally in-order to get the IPC setup correctly. However, I'm not terribly well versed in the internals of the IPC framework, so I can't be 100% sure about that. -Kyle On Fri, Aug 7, 2015 at 3:23 PM, Joshua Root j...@macports.org wrote: On 2015-8-8 07:35 , Kyle Sammons wrote: MacPorts.framework still uses a privileged helper tool to do the things that require root, right? Why couldn't it be run in this way? Uhhh, no, not as far as I know. The privileged helper is needs to be communicated with through the IPC library, which wouldn't be possible if it was launched through a shell. Why not? Doesn't it just use a unix socket? - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Looking for opinions on authorization frameworks for Pallet
Hey Ian,
Thanks for the offer, unfortunately, however, Pallet doesn't run any shell
commands (everything is passed done through spinning up a Tcl shell and
passing input/output through IPC), so I'm afraid your example wouldn't work.
Thanks again, though!
-Kyle
On Wed, Aug 5, 2015 at 5:25 PM, Ian Wadham iandw...@gmail.com wrote:
On 06/08/2015, at 4:14 AM, Kyle Sammons wrote:
Hey everyone,
Currently I'm at a fork in the road for the Revitalizing Pallet GSoC
project, and was hoping to crowd source some ideas about how to deal
with the Apple authorization framework used to get super user privileges
to allow 'port' to execute correctly under the hood. This task is the
last major one on my GSoC queue. There are three possible roads to go
down here; I don't know which one is the best or correct one, hence
the crowd sourcing here.
Here is another possibility, which I used in Fossick… Note that I went the
command-line route and used tail -f to receive output asynchronously.
You may not need that if you have gone the other route. The guts of the
authorisation is to use AppleScript. Hope this helps.
/**
* This method uses AppleScript to run a privileged Unix script
asynchronously
* in the background, with output to a file (e.g. a script containing
MacPorts'
* port install software item command). The NSTask object defined
above
* uses tail -f to collect the output as it occurs. The return string
is nil
* if the script started OK or contains an error text if it failed.
AppleScript
* is run with administrator privileges, which means that it pops up the
usual
* Apple request for an admin password when installing non-Apple software.
*/
- (NSString *) runPrivilegedScript: (NSString *) filePath
output: (NSString *) outputFilePath;
---
- (NSString *) runPrivilegedScript: (NSString *) filePath
output: (NSString *) outputFilePath
{
NSDictionary * error;
NSString * script = [NSString stringWithFormat: @do shell script \
\'%@' '%@' 21 \ \
with administrator privileges \
without altering line endings,
filePath, outputFilePath];
NSLog(@SCRIPT: %@, script);
NSAppleScript * appleScript = [[NSAppleScript new]
initWithSource:script];
if ([appleScript executeAndReturnError:error]) {
NSLog(@AppleScript running! '%@' '%@' 21 , filePath,
outputFilePath);
// Start the output-watcher.
self.task = [[NSTask alloc] init];
[self.task setLaunchPath:@/usr/bin/tail];
[self.task setArguments:[NSArray arrayWithObjects:
@-f, outputFilePath, nil]];
self.tailOfOutput = [NSPipe pipe];
self.errorOutput = [NSPipe pipe];
[self.task setStandardOutput: tailOfOutput];
[self.task setStandardError: errorOutput];
[self.task setStandardInput: [NSPipe pipe]]; // No standard input.
[self.task launch];
[[self.tailOfOutput fileHandleForReading]
readInBackgroundAndNotify];
[[NSNotificationCenter defaultCenter]
addObserver: self
selector: @selector (receiveOutput:)
name: NSFileHandleReadCompletionNotification
object: nil];
return nil;
}
else {
NSLog(@Failed to run AppleScript!\n%@, error);
return [error description];
}
// TODO: User cancelled. is a possible error reason (i.e. hit Cancel
//instead of entering a password). OS X seems to allow
unlimited
//failed attempts to enter the password.
}
0. Do nothing; leave the current code in place, but continue to ignore
it; require the user to run it with superuser privileges;
snip
Cheers, Ian W.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Looking for opinions on authorization frameworks for Pallet
On 2015-8-8 07:35 , Kyle Sammons wrote: MacPorts.framework still uses a privileged helper tool to do the things that require root, right? Why couldn't it be run in this way? Uhhh, no, not as far as I know. The privileged helper is needs to be communicated with through the IPC library, which wouldn't be possible if it was launched through a shell. Why not? Doesn't it just use a unix socket? - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Looking for opinions on authorization frameworks for Pallet
Hey Joshua, 1. is really the only reasonable option. Whether you do it now or someone else does it later, it's what we want to have in an app whose target audience includes users who don't want to use the terminal. I tried to keep the discussion more towards the implementation of it, as I could potentially create a launcher, or go through other ways to make it so you don't have to use the terminal to launch the GUI application (or visa versa). MacPorts.framework still uses a privileged helper tool to do the things that require root, right? Why couldn't it be run in this way? Uhhh, no, not as far as I know. The privileged helper is needs to be communicated with through the IPC library, which wouldn't be possible if it was launched through a shell. -Kyle On Fri, Aug 7, 2015 at 1:48 PM, Joshua Root j...@macports.org wrote: On 2015-8-8 05:23 , Kyle Sammons wrote: Hey Ian, Thanks for the offer, unfortunately, however, Pallet doesn't run any shell commands (everything is passed done through spinning up a Tcl shell and passing input/output through IPC), so I'm afraid your example wouldn't work. MacPorts.framework still uses a privileged helper tool to do the things that require root, right? Why couldn't it be run in this way? - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Looking for opinions on authorization frameworks for Pallet
On 08/07/2015 09:18 PM, Kyle Sammons wrote: That's right. I don't think it is unsolvable, just a lot of work to figure it out, but the solution we implement here could also be used for other applications. It might be worth the effort to have this. I'm not sure too many other people would be able to benefit from it as the issues we're having isn't so much with automatically generating a self-signed certificate (that part is already written), but getting that to work within the MacPorts build system. Hm, but wouldn't that be helpful for other ports installing .app bundles? Maybe I don't have enough knowledge here to decide whether it is really useful. There would not be any new functionality in the graphical frontend that could not also be exploited in 'sudo port' from the command line, right? I'm not sure what you mean by that. Would you mind rewording it? I mean, most users already run the port command as root. Any security vulnerability that can be exploited in the GUI would most probably also be exploitable from the command line when running with 'sudo port'. Or what kind of vulnerability do you have in mind? Would I have to type 'sudo pallet'? Will I be able to start the application from an app bundle? Currently yes, unless there's a way to launch an app bundle with superuser privileges that I'm unaware of. That would be very unfortunate. I would see the GUI as a way to give users easier access to MacPorts without the need to use the Terminal. Opening an app bundle should be the preferred way in my opinion. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Looking for opinions on authorization frameworks for Pallet
On 2015-8-8 05:23 , Kyle Sammons wrote: Hey Ian, Thanks for the offer, unfortunately, however, Pallet doesn't run any shell commands (everything is passed done through spinning up a Tcl shell and passing input/output through IPC), so I'm afraid your example wouldn't work. MacPorts.framework still uses a privileged helper tool to do the things that require root, right? Why couldn't it be run in this way? - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Looking for opinions on authorization frameworks for Pallet
Hey Rainer, Sorry to get back to you so late, I was a bit preoccupied yesterday. That's right. I don't think it is unsolvable, just a lot of work to figure it out, but the solution we implement here could also be used for other applications. It might be worth the effort to have this. I'm not sure too many other people would be able to benefit from it as the issues we're having isn't so much with automatically generating a self-signed certificate (that part is already written), but getting that to work within the MacPorts build system. There would not be any new functionality in the graphical frontend that could not also be exploited in 'sudo port' from the command line, right? I'm not sure what you mean by that. Would you mind rewording it? Would I have to type 'sudo pallet'? Will I be able to start the application from an app bundle? Currently yes, unless there's a way to launch an app bundle with superuser privileges that I'm unaware of. Thanks for the comments, -Kyle On Thu, Aug 6, 2015 at 6:01 AM, Rainer Müller rai...@macports.org wrote: Hello Kyle, On 2015-08-05 20:14, Kyle Sammons wrote: ** Option 0: Do nothing; leave the current code in place, but continue to ignore it; require the user to run it with superuser privileges; Pros: 1. Easiest to implement; requires no changes to the current code, allowing me to add more features to Pallet, and remove more bugs. Cons: 1. Still requires a certificate. Using a modern authorization framework requires the use of a self-signed certificate, which highly complicates the project build process, making writing a Portfile much harder. That's right. I don't think it is unsolvable, just a lot of work to figure it out, but the solution we implement here could also be used for other applications. It might be worth the effort to have this. 2. Still requires running Pallet with superuser privileges. 3. Insecure. The entire application will be running as a superuser, so any vulnerabilities that are exploitable will allow a hacker to run as root. There would not be any new functionality in the graphical frontend that could not also be exploited in 'sudo port' from the command line, right? ** Option 2. Remove all authorization frameworks from Pallet, and require the user to run it with superuser privileges: Pros: 1. Pretty easy to implement. I could implement this solution in a day or two, allowing me to add more features to Pallet, and remove more bugs. 2. Doesn't require a certificate. Using a modern authorization framework requires the use of a self-signed certificate, which highly complicates the project build process, making writing a portfile much harder. 3. Easiest to support. Running an application with sudo will really never be deprecated, and will work on every OS X version. Would I have to type 'sudo pallet'? Will I be able to start the application from an app bundle? 4. Smallest code-base. Cons: - 1. Insecure. The entire application will be running as a superuser, so any vulnerabilities that are exploitable will allow a hacker to run as root. See above. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Looking for opinions on authorization frameworks for Pallet
Hey Rainer, I mean, most users already run the port command as root. Any security vulnerability that can be exploited in the GUI would most probably also be exploitable from the command line when running with 'sudo port'. Or what kind of vulnerability do you have in mind? It'd most likely be more insecure due to the fact that Pallet has a constant Tcl shell running in the background, as well as it's running the entire GUI framework as root. That would be very unfortunate. I would see the GUI as a way to give users easier access to MacPorts without the need to use the Terminal. Opening an app bundle should be the preferred way in my opinion. In order to achieve that, I'd have to replace the current authorization framework (option 1 of the original email). The only other option is that I may be able to get a launcher type script working (double-click and a GUI-sudo would launch Pallet as root). -Kyle On Fri, Aug 7, 2015 at 1:34 PM, Rainer Müller rai...@macports.org wrote: On 08/07/2015 09:18 PM, Kyle Sammons wrote: That's right. I don't think it is unsolvable, just a lot of work to figure it out, but the solution we implement here could also be used for other applications. It might be worth the effort to have this. I'm not sure too many other people would be able to benefit from it as the issues we're having isn't so much with automatically generating a self-signed certificate (that part is already written), but getting that to work within the MacPorts build system. Hm, but wouldn't that be helpful for other ports installing .app bundles? Maybe I don't have enough knowledge here to decide whether it is really useful. There would not be any new functionality in the graphical frontend that could not also be exploited in 'sudo port' from the command line, right? I'm not sure what you mean by that. Would you mind rewording it? I mean, most users already run the port command as root. Any security vulnerability that can be exploited in the GUI would most probably also be exploitable from the command line when running with 'sudo port'. Or what kind of vulnerability do you have in mind? Would I have to type 'sudo pallet'? Will I be able to start the application from an app bundle? Currently yes, unless there's a way to launch an app bundle with superuser privileges that I'm unaware of. That would be very unfortunate. I would see the GUI as a way to give users easier access to MacPorts without the need to use the Terminal. Opening an app bundle should be the preferred way in my opinion. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Looking for opinions on authorization frameworks for Pallet
On 2015-8-6 04:14 , Kyle Sammons wrote: Hey everyone, Currently I'm at a fork in the road for the Revitalizing Pallet GSoC project, and was hoping to crowd source some ideas about how to deal with the Apple authorization framework used to get super user privileges to allow 'port' to execute correctly under the hood. This task is the last major one on my GSoC queue. There are three possible roads to go down here; I don't know which one is the best or correct one, hence the crowd sourcing here. 0. Do nothing; leave the current code in place, but continue to ignore it; require the user to run it with superuser privileges; 1. Update the authorization framework pallet currently uses, and use it, requesting authorization only when needed; 2. Remove all authorization frameworks from it, and require the user to run it with superuser privileges. 1. is really the only reasonable option. Whether you do it now or someone else does it later, it's what we want to have in an app whose target audience includes users who don't want to use the terminal. I think that while we have your undivided attention, we would rather have you working on the hardest problems that you can solve. Anyone can do the easy stuff later, right? :) - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Looking for opinions on authorization frameworks for Pallet
Hello Kyle, On 2015-08-05 20:14, Kyle Sammons wrote: ** Option 0: Do nothing; leave the current code in place, but continue to ignore it; require the user to run it with superuser privileges; Pros: 1. Easiest to implement; requires no changes to the current code, allowing me to add more features to Pallet, and remove more bugs. Cons: 1. Still requires a certificate. Using a modern authorization framework requires the use of a self-signed certificate, which highly complicates the project build process, making writing a Portfile much harder. That's right. I don't think it is unsolvable, just a lot of work to figure it out, but the solution we implement here could also be used for other applications. It might be worth the effort to have this. 2. Still requires running Pallet with superuser privileges. 3. Insecure. The entire application will be running as a superuser, so any vulnerabilities that are exploitable will allow a hacker to run as root. There would not be any new functionality in the graphical frontend that could not also be exploited in 'sudo port' from the command line, right? ** Option 2. Remove all authorization frameworks from Pallet, and require the user to run it with superuser privileges: Pros: 1. Pretty easy to implement. I could implement this solution in a day or two, allowing me to add more features to Pallet, and remove more bugs. 2. Doesn't require a certificate. Using a modern authorization framework requires the use of a self-signed certificate, which highly complicates the project build process, making writing a portfile much harder. 3. Easiest to support. Running an application with sudo will really never be deprecated, and will work on every OS X version. Would I have to type 'sudo pallet'? Will I be able to start the application from an app bundle? 4. Smallest code-base. Cons: - 1. Insecure. The entire application will be running as a superuser, so any vulnerabilities that are exploitable will allow a hacker to run as root. See above. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Looking for opinions on authorization frameworks for Pallet
Hey everyone, Currently I'm at a fork in the road for the Revitalizing Pallet GSoC project, and was hoping to crowd source some ideas about how to deal with the Apple authorization framework used to get super user privileges to allow 'port' to execute correctly under the hood. This task is the last major one on my GSoC queue. There are three possible roads to go down here; I don't know which one is the best or correct one, hence the crowd sourcing here. 0. Do nothing; leave the current code in place, but continue to ignore it; require the user to run it with superuser privileges; 1. Update the authorization framework pallet currently uses, and use it, requesting authorization only when needed; 2. Remove all authorization frameworks from it, and require the user to run it with superuser privileges. I've made a pros/cons list of each choice below, that I can think of. Thanks for your thoughts and opinions, -Kyle ** Option 0: Do nothing; leave the current code in place, but continue to ignore it; require the user to run it with superuser privileges; Pros: 1. Easiest to implement; requires no changes to the current code, allowing me to add more features to Pallet, and remove more bugs. Cons: 1. Still requires a certificate. Using a modern authorization framework requires the use of a self-signed certificate, which highly complicates the project build process, making writing a Portfile much harder. 2. Still requires running Pallet with superuser privileges. 3. Insecure. The entire application will be running as a superuser, so any vulnerabilities that are exploitable will allow a hacker to run as root. ** Option 1. Update the authorization framework pallet currently uses, and use it, requesting authorization only when needed: Pros: 1. Most secure. Uses code-signing to verify nothing has been tampered with, and runs the base executable with only user-privileges. 2. Apple approved: This is the Apple-approved way of getting superuser privileges when needed. Cons: - 1. Hardest to implement. As in, it would most likely take up the rest of the time I have left to work on this project, and even then it might not be 100% implemented. 2. Hardest to support. Apple has a new authorization framework on almost every version of OS X, meaning that I'd either have to support all of them (which is an obscene amount of work), or pick one that will eventually be deprecated in one or two OS X lifecycles, and won't work on any previous version of OS X. ** Option 2. Remove all authorization frameworks from Pallet, and require the user to run it with superuser privileges: Pros: 1. Pretty easy to implement. I could implement this solution in a day or two, allowing me to add more features to Pallet, and remove more bugs. 2. Doesn't require a certificate. Using a modern authorization framework requires the use of a self-signed certificate, which highly complicates the project build process, making writing a portfile much harder. 3. Easiest to support. Running an application with sudo will really never be deprecated, and will work on every OS X version. 4. Smallest code-base. Cons: - 1. Insecure. The entire application will be running as a superuser, so any vulnerabilities that are exploitable will allow a hacker to run as root. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Looking for opinions on authorization frameworks for Pallet
On 06/08/2015, at 4:14 AM, Kyle Sammons wrote:
Hey everyone,
Currently I'm at a fork in the road for the Revitalizing Pallet GSoC
project, and was hoping to crowd source some ideas about how to deal
with the Apple authorization framework used to get super user privileges
to allow 'port' to execute correctly under the hood. This task is the
last major one on my GSoC queue. There are three possible roads to go
down here; I don't know which one is the best or correct one, hence
the crowd sourcing here.
Here is another possibility, which I used in Fossick… Note that I went the
command-line route and used tail -f to receive output asynchronously.
You may not need that if you have gone the other route. The guts of the
authorisation is to use AppleScript. Hope this helps.
/**
* This method uses AppleScript to run a privileged Unix script asynchronously
* in the background, with output to a file (e.g. a script containing MacPorts'
* port install software item command). The NSTask object defined above
* uses tail -f to collect the output as it occurs. The return string is nil
* if the script started OK or contains an error text if it failed. AppleScript
* is run with administrator privileges, which means that it pops up the usual
* Apple request for an admin password when installing non-Apple software.
*/
- (NSString *) runPrivilegedScript: (NSString *) filePath
output: (NSString *) outputFilePath;
---
- (NSString *) runPrivilegedScript: (NSString *) filePath
output: (NSString *) outputFilePath
{
NSDictionary * error;
NSString * script = [NSString stringWithFormat: @do shell script \
\'%@' '%@' 21 \ \
with administrator privileges \
without altering line endings,
filePath, outputFilePath];
NSLog(@SCRIPT: %@, script);
NSAppleScript * appleScript = [[NSAppleScript new] initWithSource:script];
if ([appleScript executeAndReturnError:error]) {
NSLog(@AppleScript running! '%@' '%@' 21 , filePath,
outputFilePath);
// Start the output-watcher.
self.task = [[NSTask alloc] init];
[self.task setLaunchPath:@/usr/bin/tail];
[self.task setArguments:[NSArray arrayWithObjects:
@-f, outputFilePath, nil]];
self.tailOfOutput = [NSPipe pipe];
self.errorOutput = [NSPipe pipe];
[self.task setStandardOutput: tailOfOutput];
[self.task setStandardError: errorOutput];
[self.task setStandardInput: [NSPipe pipe]]; // No standard input.
[self.task launch];
[[self.tailOfOutput fileHandleForReading] readInBackgroundAndNotify];
[[NSNotificationCenter defaultCenter]
addObserver: self
selector: @selector (receiveOutput:)
name: NSFileHandleReadCompletionNotification
object: nil];
return nil;
}
else {
NSLog(@Failed to run AppleScript!\n%@, error);
return [error description];
}
// TODO: User cancelled. is a possible error reason (i.e. hit Cancel
//instead of entering a password). OS X seems to allow unlimited
//failed attempts to enter the password.
}
0. Do nothing; leave the current code in place, but continue to ignore
it; require the user to run it with superuser privileges;
snip
Cheers, Ian W.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
