> On 2014/02/22, at 11:13, Bradley O'Hearne <br...@bighillsoftware.com> wrote: > >> On Feb 21, 2014, at 3:02 PM, Jens Alfke <j...@mooseyard.com> wrote: >> >> >>> On Feb 21, 2014, at 1:26 PM, Bradley O'Hearne <br...@bighillsoftware.com> >>> wrote: >>> >>> If that is the case, then once I can officially confirm this, then I’ll >>> drop the pursuit. >> >> The key word is “officially”. There’s not really any point to discussing it >> here. We already had this exact same discussion a few months ago and nothing >> came of it; I’m not sure why you’re asking again and expecting more. > > The last time I posted about this issue was 3/5/2013. There are several > reasons why I’m asking again: > > - I have since spoken directly with Apple engineers who said the use-case was > legit, and there was an outside possibility this might appear in later OS X > releases. > > - The issues has been open in Apple radar since June 2013 ― I hadn’t seen any > movement, and wondered if perhaps someone else was aware of a change which > would positively affect the situation. > > - There has been a major OS X release since then (Mavericks). > > - The original discussion netted no definitive answer. > > - This has become a significant issue to my client’s product design and > strategy, and is becoming an obstacle to gaining business with certain > customers on OS X. > > …and I do expect that given a year of time, it is within the realm of > possibility that Apple has encountered others with similar needs to ours, and > may have made some changes we could benefit ― likewise, that there are others > on this list which may have encountered the same problem and tried to solve > it (which by virtue of some offline responses I’ve received, is indeed the > case). > > If the use-case isn’t your bag, no worries, just don’t reply. But don’t be > cynical and try to kill conversation because it isn’t your thing. That not > only doesn’t help my immediate question, but keeps others from posting their > issues who don’t really want to get roasted (which also by virtue of offline > responses I’ve received, is indeed the case). > Hi Brad
Nobody is trying to attack you here. They're pointing out valid security issues which are true on all platforms. This kind of topic comes up annually at least on this list. Often from folks who haven't really done a full analysis and they often come away from the list responses feeling a bit bruised. Many of the first responders on the list are very very seasoned developers. They're just trying to help. They're not ego driven but quality driven folks. On any platform, you will need to basically install and run a root kit. Meaning you need to install software that runs as root. That is not a usual Cocoa user experience, but it's the right path for this scenario. You can use the Quartz Display Services API to control the attached displays (see the "capture" functions for capturing control of the display) and you can use CGEvent APIs to control input via event taps. That will get you part of what you need for UI and input control. The I/O Kit framework will allow you to control hardware at a low level. Kernel level stuff. Not simple. But possible to basically prevent undesired hardware events to some degree. Let's not side step any of the other security concerns though. The classic saying "Boot access is Root access" should sum up much of it. Any other admin or root process outside of your visibility and control is a potential risk that must be evaluated and should be checked. It is impossible to verify a system is not compromised when the system is outside of physical control at any time prior to running or installing your app. That's what people are getting at. Again, platform agnostic. On some level you place a certain amount of trust and agreement in the user. Installing a root kit is your best bet in terms of software solutions on any platform and, really, physically controlling hardware is the best of all. Your clients need to know that. If they've been convinced of anything else, either they've been lied to by others or they listened to people who really didn't understand security fundamentals. If they're really aware of these issues, then they should have established guidelines on acceptable risks that are not severe enough to them to spend money on, redesign for, or spend time on. People here are exactly pointing these things out for the benefit of all on the list. At the end of the day though, on any platform, it is possible another process is running and recording the display stream, input stream, or network traffic or disk or memory writes before your process runs. You'd do well to analyze what processes could and should be running while yours runs and limit it to that as well. (Whitelisting) A DTS incident might help you to find out what that might need to be. That will require custom software on any platform. Basically, without managing a way to make sure a system (any platform) is cleanly installed prior to the exam and hardware access is limited and controlled, you cannot guarantee software security. Security is always a set of informed compromises. I don't know of a consumer platform that provides a true kernel and window server level secure kiosk mode API out if the box. (Meaning one that makes it easy I think people are just trying to set realistic expectations. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
