Looking for opinions on authorization frameworks for Pallet

[Kyle Sammons]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150805/6b56e34d/attachment.html>