11:23 a.m.
https://bugzilla.redhat.com/show_bug.cgi?id=1310542
https://fedorahosted.org/fedora-security-team/ticket/1
I'm not sure if this belongs in security@ or security-team@ so I've
just flipped a coin.
On macOS there are three distribution+security paths:
- unsigned, and the user is blocked from running the app by default
but they can disable this one time for that application installer or
for all installers
- dev signed, developer distributed
- dev signed, and Apple signed, App Store distributed
Dev keys are only available through the Apple Developer Program, and
only sign code through XCode. There is a way to sign code through a
3rd party but macOS treats it as unsigned, the user would have to use
the CLI to verify the signing of the binary.
There are details in here I'm not certain of, but there is a
qualitative difference in sandboxing of App Store distributed apps.
I'm not certain they can do privilege escalation. In order to image an
ISO to a USB stick on macOS I have to use 'sudo dd' to have the
privileges to write to a raw device.
As for compiling, I'm not totally certain it has to happen within
XCode on macOS, but the signing of the binary happens with XCode which
only runs on macOS. Primary development can happen elsewhere, but
eventually it gets built on Apple hardware, OS, and dev tools. A good
chunk of that is controllable by CLI.
I wonder if there's a way to ship this as a Docker for Mac container
instead? It's still beta, but uses HyperKit framework which is an
Apple provided library rather than depending on VirtualBox. So I'd
also consider evaluating this path since it may turn out to be the
path of least resistance for getting an initial tool on macOS.
--
Chris Murphy
9:38 p.m.
On Fri, Jun 24, 2016 at 12:24 PM Chris Murphy <lists(a)colorremedies.com>
wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1310542
https://fedorahosted.org/fedora-security-team/ticket/1
I'm not sure if this belongs in security@ or security-team@ so I've
just flipped a coin.
On macOS there are three distribution+security paths:
- unsigned, and the user is blocked from running the app by default
but they can disable this one time for that application installer or
for all installers
- dev signed, developer distributed
- dev signed, and Apple signed, App Store distributed
Dev keys are only available through the Apple Developer Program, and
only sign code through XCode. There is a way to sign code through a
3rd party but macOS treats it as unsigned, the user would have to use
the CLI to verify the signing of the binary.
There are details in here I'm not certain of, but there is a
qualitative difference in sandboxing of App Store distributed apps.
I'm not certain they can do privilege escalation. In order to image an
ISO to a USB stick on macOS I have to use 'sudo dd' to have the
privileges to write to a raw device.
As for compiling, I'm not totally certain it has to happen within
XCode on macOS, but the signing of the binary happens with XCode which
only runs on macOS. Primary development can happen elsewhere, but
eventually it gets built on Apple hardware, OS, and dev tools. A good
chunk of that is controllable by CLI.
I wonder if there's a way to ship this as a Docker for Mac container
instead? It's still beta, but uses HyperKit framework which is an
Apple provided library rather than depending on VirtualBox. So I'd
also consider evaluating this path since it may turn out to be the
path of least resistance for getting an initial tool on macOS.
Chris,
Thanks for the info, it sounds like the macOS application really requires a
Mac to build then as, at least in my opinion, Apple's signing process
provides the users with the easiest workflow, and the highest level of
assurance that the code is legitimate.
Can you also provide us information on the Windows build process?
Thanks,
Zach Oglesby
2:54 p.m.
On Tue, Jun 28, 2016 at 8:38 PM, Zachary Oglesby <zach(a)oglesby.co> wrote:
Thanks for the info, it sounds like the macOS application really
requires a
Mac to build then as, at least in my opinion, Apple's signing process
provides the users with the easiest workflow, and the highest level of
assurance that the code is legitimate.
Yes. What I'm uncertain about is what this would look like if it were
shipped as a container for Docker on Mac (using HyperKit instead of
Virtual Box) if there's any kind of code signing there, or if it's
obviated because it's in a container and thus "safe". But then also
whether the container has the necessary privilege to dd to a raw
device.
Can you also provide us information on the Windows build process?
No idea really. I asked a colleague who does Windows IT and he doesn't
know for sure either. I think that world is much more variable. He
suspects that it's possible to get a 3rd party certificate issued,
signed by an intermediate certificate already included in Windows, and
Windows will run binaries signed with that 3rd party cert. But... I
don't know. So it might be easier than on macOS.
I know there's a preference to have a native installer. But it seems
fairly clear this could be a Docker or Flatpak package for Linux
distros. If that's going to happen anyway, the installation of Docker
on Mac (or Windows) seems a lot easier to evaluate than even the most
rudimentary evaluation of either Apple or Microsoft's native app
requirements.
There are some very neat advantages if this could be done as a
container, aside from far fewer variations between the tools. Doing
the overlay setup, currently not supported in Fedora Media Writer, but
desired, means having access to Linux tools to write out the necessary
metadata. If this is already available in the container no matter the
platform, it's easier than having to write an installer specific
library to do that. And so on.
--
Chris Murphy
2850
days inactive
2857
days old
security@lists.fedoraproject.org
2 comments
2 participants
participants (2)
-
Chris Murphy -
Zach Oglesby