Tag Archives: Cocoa

Cocoa Development Objective C OS X

Follow-up: OS X privilege escalation without using deprecated methods

March 5, 2012 – 3:47 pm

I posted a few months ago about the problems I’d encountered with performing privileged actions from a Mac OS X app – in my case, installing a command line utility in /usr/local/bin – and that all the examples of this that I’d come across used an approach which was now deprecated. You can find my original post here:
Escalating privileges on Mac OS X securely, and without using deprecated methods.

I had failed to produce a shrink-wrapped working example to go with the discussion, primarily because extracting it into a standalone example would take a while and I made the post a couple of days before I went on holiday. I also didn’t know whether anyone else actually cared about the subject enough for it to be worth me doing it!

Well, perhaps I should have known better, because I’ve had quite a few requests for such an example since then :) I finally got around to doing this at the weekend – and actually when I came to do it I understood why people had pestered me for it, because it took me a while to get things configured just right in a fresh project! Mostly, it’s that there are quite a few things that can go wrong outside the code, both in the project settings and the plists because of the code signing requirements.

So anyway, here’s the project: PrivilegedHelperExample on Bitbucket. Please make sure to check the ReadMe.txt – despite being shrink-wrapped, you will need to add your own code signing identity before you can compile the code, and you will need to reflect the name of your certificate in a few places, which I’ve listed. I’ve also tried to point you at the relevant pain points you may encounter when replicating the result in a different project.

The majority of this code is just the Apple example code from BetterAuthorizationSample and SMJobBless, grafted together, de-duplicated and tweaked. All the changes I made can be considered public domain.

Enjoy!

Tags , , , , , , | Permalink | Comments (8)
Cocoa Development Objective C OS X

Escalating privileges on Mac OS X securely, and without using deprecated methods

November 25, 2011 – 5:04 pm

This week I implemented a much-requested feature in SourceTree for the upcoming 1.3 release (beta 1 went out on Monday, this will make it into beta 2) – a command-line tool so you can quickly pull up SourceTree for the repository you’re in from a terminal. Writing the command-line tool was trivial, but when I came to implement the menu item which would install it in /usr/local/bin, which inherently needs privilege escalation, it turned out to be a lot more complicated than I expected.

How so? Surely lots of people have done this sort of thing before? Well, that’s true, they have – but the problem is that just about all of the existing examples of this use the Authorization Services API call AuthorizationExecuteWithPrivileges – and this method is deprecated in OS X 10.7 (Lion). Now, of course that doesn’t stop you using it (yet), provided you’re willing to turn off the warning that building against the 10.7 SDK gives you, but any programmer worth his salt should take deprecation as a hint that they should be looking for another way.

There are basically 3 ways to escalate privileges on OS X, and only one of them is now recommended:

  1. Use a helper tool which has its setuid bit set so that it runs as root. Risky if that tool gets compromised, and the setuid bit can be lost, needing reinstatement by another privileged task.
  2. Execute a command as root via AuthorizationExecuteWithPrivileges. As mentioned above, this is now deprecated, and again if a hacker compromises either the app or the tool being launched, bad things can happen.
  3. Ask Launch Services to install a privileged helper tool via SMJobBless. This helper is subsequently run by launchd as root when invoked via a Unix socket, and can perform privileged tasks. Importantly, code signing is verified at both ends by Launch Services at install time to prevent tampering with either binary.

Clearly option 3 was the way to go – the only ‘downside’ about it is that is does require that you have the ability to sign your application and helper tool. I already have valid code signing certificates because I deploy on the App Store, so this isn’t an issue (even though this functionality won’t actually be in the App Store version of SourceTree because Apple disallow installer behaviour there, I still sign with the same certs). In fact, the fact that I know my app and helper tool can’t be interfered with without the code signatures becoming invalid is very reassuring. Given that it only costs $99 per year to be on the Mac Developer Programme which allows you to get certificates (even if you don’t deploy on the App Store), it’s something serious developers should consider strongly.

SMJobBless is ideally suited to installing daemons, but it’s perfectly acceptable to install tools which run simple one-off tasks too. When setting up the plist for the helper, you specify that it is ‘OnDemand’, with no ‘KeepAlive’ which means it’s not started by Launch Services at startup, only when a Unix socket is opened, and shuts down very quickly if there’s no activity. Unfortunately the SMJobBless example doesn’t do anything except to show you how to install a tool, it doesn’t tell you how to implement that tool to do anything useful, or how to call it from your main application.

To see how to do that, you need to refer to BetterAuthorizationSample , which includes a re-usable library for this. Ironically though, this example uses AuthorizationExecuteWithPrivileges to install its helper (this example pre-dated its deprecation in favour of SMJobBless). So you have to remove all the code associated with installation; you won’t need it anyway since SMJobBless does that function better. You keep the rest which gives you a framework for implementing and calling the helper. So here’s what I did:

  1. Implement the installation of a privileged helper, based directly on the SMJobBless example. I needed to change the bundle IDs and the certificate CN’s to match my setup of course.
  2. Extend the plist files from SMJobBless to register the helper with a socket. This was basically a case of copying the settings from the BetterAuthorizationSample plists, which already does this.
  3. Bring in BetterAuthorizationSampleLib.c/.h to assist with implementation of the helper, and the code for calling it in the app, but remove everything in the ‘Installation’ section. This eliminates all the references to AuthorizationExecuteWithPrivileges – we’re doing the install with SMJobBless so don’t need that.
  4. Follow the BetterAuthorizationSample for the implementation of the helper, and the bit in the application where you call the helper to perform privileged operations.

So in my case, the following happens when you click ‘Install Command Line Tool’ in SourceTree:

  1. A privileged helper is installed in Launch Services using SMJobBless. OS X checks the code signatures on both ends to ensure that the helper and the application asking to install it are valid (must be signed with my cert, and that cert must be issued by Apple).
  2. A connection is opened to the privileged helper over a socket which causes launchd to start it up
  3. I ask the helper via the BetterAuthorizationSampleLib to install the command-line tool in /usr/local/bin. As an additional check, the helper validates via ‘codesign -v  -R=”conditions”‘ that this tool is code signed with my cert (again, must be issued by Apple) – this is to prevent anyone else sniffing out this socket and trying to use it to install other things. If that passes, it installs the command.

This is quite a long-winded process compared to just calling a ‘cp’ command via AuthorizationExecuteWithPrivileges, but it’s also a lot more secure, since a malicious person can’t alter any of the moving parts without invalidating the code signatures. You’re also insulated from future changes when inevitably AuthorizationExecuteWithPrivileges is removed entirely.

I apologise for the lack of a pre-packaged example here – I haven’t had time to extract one from my own implementation yet. However, as described above if you start with the SMJobBless sample and add-in the BetterAuthorizationSample, removing from the latter everything associated with installation, you’re basically there. If I get chance later I’ll post a shrink-wrapped example.

I hope that helps someone – I found there to be little information on this subject that was up-to-date, and lots of older information that was misleading so maybe this will save someone some time. Ideally, I hope Apple will combine the SMJobBless and BetterAuthorizationSample some time to produce a 10.7-compliant official example.

Tags , , , | Permalink | Comments (28)
Cocoa Development Objective C Open Source OS X

SSSelectableToolbar

June 20, 2011 – 1:32 pm

A common requirement in any Cocoa application is a preference pane style window where each toolbar item switches to a different view in the main window, resizing as necessary. I’ve used BWToolkit to do this in the past, which provides BWSelectableToolbar. However, there are a few issues with using BWToolkit:

  1. If you want to deploy on the Mac App Store, You have to customise it to remove all uses of private methods, since those are banned on the App Store.
  2. It sometimes crashes Interface Builder – usually not fatally but it can get awkward
  3. Sometimes it gets the window height slightly too tall when switching panes – I’ve patched it to try to cope with this but it still happens sometimes
  4. It relies on using IB plugins. XCode 4 does not support IB plugins anymore – although you can still build the code, you can’t edit the nibs anymore

I’ve just been coping with 1, 2 & 3 so far, but 4 was the killer which made me come up with my own alternative: SSSelectableToolbar.

With SSSelectableToolbar, you can still do the preference pane setup entirely within Interface Builder, but it doesn’t require any plugins. There are a couple of extra steps required because of this, but they’re not onerous and still better than setting it all up in code.

The license is permissive MIT, usage is in the README, and there’s an example demo to show how it works. I hope it’s useful to someone else too.

Tags , , , , | Permalink | Comment (1)
Cocoa Development Objective C

Cocoa tip: using custom outline view cells designed in IB

August 8, 2010 – 11:13 am

I only started learning Objective-C and Cocoa in mid-May, and for the first time I think I actually have a tip to contribute to the wider community. It’s about using custom cells in NSOutlineView, but those which you want to design inside Interface Builder rather than drawing manually.

If you’re an iOS developer, you’ll be wondering why this deserves a blog post – it’s easy to do in Cocoa Touch! Well, yes it is easy on iOS, because Apple have specifically allowed you to design table view cells in Interface Builder. When targetting Mac OS X though, it’s actually pretty awkward, and here’s why: in Cocoa Touch, the class which draws the cells in a table is UITableViewCell, which is a subclass of UIView – meaning you can drag one onto the canvas in Interface Builder and lay stuff out right there. In Cocoa, in contrast, the cell is simply represented by NSCell, which is not an NSView subclass. This means Interface Builder will not let you play with them, you draw them by implementing drawWithFrame:inView: instead. I think Apple realised the problem with this design in time for Cocoa Touch but obviously felt they couldn’t break the existing Cocoa interfaces. There are also many differences between the instantiation of NSCell versus UITableViewCell – there’s only one NSCell for all rows in a table / outline view, compared to a type-indexed pool in Cocoa Touch.

The problem boiled down to this: if the contents of your table / outline cell is non-trivial, or if you just don’t want to write a bunch of layout code, it’s a PITA to implement a custom look in NSOutlineView, such as the one in the picture, especially if you want custom controls embedded in it. For my current Cocoa app, I really wanted to design my cells (and I have 2 different styles for group levels and detail levels) in Interface Builder to save me hassle, including using Cocoa Bindings to hook up some dynamic fields within. Many internet searches later, and mostly the answer I found was that it couldn’t be done. Luckily, I’m too stubborn to take no for an answer, and eventually I figured out a way to do it. Details are after the jump, with an example project to show it in action.

read more »

Tags , , , , , , , , | Permalink | Comments (11)
Development OS X Personal

Taking a bite of the Apple

May 16, 2010 – 2:24 pm

Giving up the leadership of OGRE was a sad moment for me, but in hindsight it has also been rather liberating. For 10 years I’d spent most of my energy on OGRE or on projects that were related to OGRE. There was an implicit understanding both from the community and from myself that everything I embarked on would in some way tie into OGRE – and indeed my business has always been based on a constant balancing act between how I can make a living while also promoting and advancing OGRE. I’d tended to major on the latter rather than the former most of the time as it happens, because I had an emotional attachment to the project and a feeling of responsibility and custodianship that I took very seriously. So when I finally admitted to myself that my back couldn’t take the ongoing demands of being an open source leader as well as making a living, the big question was: what next?

Over the years I’ve learned a couple of things about choosing what projects to work on – follow your gut, and work on things you’d do even if there was no money in it. Yes, you need to do a business case and convince yourself that there’s a viable market for what you have in mind, but all that’s irrelevant if you don’t feel strongly about what you’re doing, because it’s passion and enthusiasm that will get you through the difficult times. So I sat down and gave some thought to what really excited me these days, what I liked using and what technical directions piqued my interest. I still find 3D and games fascinating, but they’re far from my only interests.

So, I realised that one area that I’ve been dying to get my teeth into properly for ages but had never found the time before, was coding specifically for Mac OS X. In 3 years I’ve gone from a total newcomer to the platform, to a staunch advocate of it. However until now I’d never really had time to play with developing on it, beyond porting cross-platform C++ code and providing / using intermediate libraries. One thing I learned in those 3 years as a user was how much better applications designed for OS X felt to use compared to those that were just ported via a common UI layer (like wxWidgets / Qt), and I’m convinced now that while cross-platform infrastructural code is great, user experiences are far better when designed with the specific platform in mind – increasingly that means OS and physical device now of course. Sure, cross-platform UIs save the developer time, but the result is often a watered-down experience – early on I liked OS X applications that felt like Windows, or ran the same on both platforms – now I  do not. Such carbon-copying applications were helpful while I was unfamiliar with the platform, but now it’s just glaring to me how basic their compatibility with the OS typically is, and how the UI styles clash with the expected standards.

So, I decided I wanted to learn how to target OS X specifically, and had a couple of ideas for projects I could do with it, which meant learning Objective-C. At first, I hated it and tried to escape via more familiar technologies like Objective-C++ and PyObjC. Ultimately I found shortcomings and limitations of those routes and returned to Objective-C, and the more I used it, the more my animosity toward it diminished. In the end I realised the problem was that I needed to adapt to the environment, rather than try to adapt it to my previously learned styles and behaviours. Sure, missing elements like namespaces might still nag me, but on balance the blend of static and dynamic language elements works very well for the intended use. And besides, I really didn’t want to be ‘that guy’ – the programmer that having decided one language / tech is ‘the best’, then tries to apply it everywhere, regardless of suitability; I like to think I’m a bit more flexible & multicultural than that.

I’ve also learned that Cocoa is a very, very smart system. Mad as a bison if you’re used to other systems beforehand, but persevere with it and resist the urge to hide it under some vanilla layer that you’re already familiar with, and you discover it’s really very powerful. Not to mention the Core Animation and Core Graphics frameworks are a lot of fun.

It’s funny, I’ve spent so many years concerning myself with providing compatibility across multiple OS’s, multiple GPUs, multiple render APIs, and multiple drivers, it’s a genuine joy to actually forget all that for a while, and concentrate on an end goal with a finite number of permutations for a change – and not to shy away from using platform-specific features.

While I’m still very much an advocate of open systems, I look at things slightly differently now – that data & protocols should be open, and that we should all re-use & collaborate on common, preferably open source infrastructure (like OGRE), but that the ‘last mile’ to the user is the least suitable for generalisation, because the more specific you can make that interface to what the user expects on their OS & device, the better that experience will be. And at the end of the day to the user, that experience is the application, and thus all that really matters – and I feel that Apple gets that, in a way that very few others do.

So, I’m having a great time learning to be an Apple developer so far, I’m going to see where this takes me for a while. My gut says it feels right, and I’ve learned to listen to my gut :) I love the platform, it’s a total change of pace and technology, it’s something I’ve had an interest in for a while, and the Mac has quite a thriving community of quality independent app developers that I can try to join – what’s not to like?

Tags , , , , , | Permalink | Comments (14)