Looking for opinions on authorization frameworks for Pallet

[Kyle Sammons]

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 <raimue at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150807/20e5afc5/attachment.html>