WWDC2001 Session 306

Transcript

Kind: captions Language: en good morning and thank you for coming to the authorization API session I want to apologize for the misprint that you might have seen which showed this as authentication that's my fault I got this a changes in at the wrong time and they didn't get reflected out onto the website so we will be talking about authorization in this session not authentication I'm Craig Keithley I'm the security and cryptography technology manager in Apple's Worldwide Developer Relations group I work closely with the engineers on all security aspects and I'm pleased to to bring up Michael Brauer to talk about the authorization api's thanks I'm here to talk about authorization and authentication on that host end I'll start off by talking about some recommended ways to use the authorization API and what you as developers can do to make OS 10 more secure by using the authorization API so so the things you'll learn in the session is how to build applications that need access to privileged parts of the system unlike Mac OS 9 Mac OS 10 is based on UNIX and in UNIX there's a difference between user process and process running is root not not every process has the ability to make every kind of change you would might want to make to the system for example if you're writing a web server you can't bind to port slower than port 1,000 this is traditional using UNIX thing so in order to bind to a lower port you'd actually need root access at least for a while and one of the things the authorization API will help you do is build applications to work in that way while not compromising security another thing to learn is to build installers that for those of you writing third-party installers to install those applications that need privileged access to the system so how will give you some api's that will let you write an installer to access privileged parts of the system and like I said before access privileged system calls without actually running your entire application with root privileges one reason you don't want to run your entire application with root privileges is that let's say you're a a cocoa app there's a number of things that dynamically get loaded when a cocoa app launches like bundles and things like that that let you enhance the app that's normally okay and it lists the user customized the environment for all their applications however if the application is running with brewed privileges you don't really want some bundle picked up out of the users home directory to just be loaded so it's much better to try and minimize the part of your application to a small well understood component that runs with with elevated privileges so first part I'll talk about understanding authorization so what authorization is is the it answers the question of may I do something or can I do this rather than Who am I authentication that answers the Who am I question authorization makes the access control decision so and I'll talk about some of the things what it does and doesn't do and finally I'll go over the actual API so understanding authorization so like I said authorization versus authentication authorization builds on top of authentication you use authentication to make an authorization decision for example if someone wants access to a privileged application you would have to first authenticate as a user and then in the current set up in Mac OS 10 we also check if you happen to be a member of the admin group which is actually the authorization step in the future will actually allow for much more flexible raishin of that where the administrators will be able to configure different rights groups and have different different administrators or different people have different privileges in the in the typical home end-user case of course we'll just have that the setup will be very similar to what it is today where the owner of the machine can do whatever they want with the machine you know there might be different setup like a lab in a in a k-12 institution where you don't really want the students to be able to change anything in the system that there's only certain people that can do that and you might actually want to divide that up into different people that have the ability to do different things with the system so why use authorization as as the authorization we're providing so one of the reasons is that it's much better than the current ad-hoc methods used for performing authorization to give you an example the way UNIX determines whether you can log in is if you're in the UNIX password database and you happen not to be in the Etsy no login file then you're okay the way ftp lets you log in is a similar mechanism but but yet again slightly different each each protocol and each way to access the system traditionally in UNIX uses its own ad-hoc method and in many cases authorization isn't even performed it's just as soon as you've authenticated it's assumed that you also may also are may access this service by using authorization you're making an explicit decision which means you can have a user in the system which doesn't automatically mean he can use every single service available in the system so you can control access to which parts of the system you want people to have access to so some of some of the benefits of having a centralized authorization API as we're providing is it makes your applications easier to audit like I said before but one of the things we'll talk about later is the ability for you to split your application into two components one component running non-privileged and one with elevated privileges and the part with elevated privileges is going to be much smaller depending on less external frameworks which will make it easier for you to audit because unlike on on Mac OS 9 on UNIX when you're running something with root privileges you really want to make sure you walk through every single line of code to make sure that your application isn't causing the next certain vizor e security vulnerability against against our operating system because if we make you and your company look really bad so the other thing it's it's configurable it's securable which means that in the default out-of-the-box experience the way we'll ship it it'll just be easy to use in your app probably won't work any different from how it worked on OS 9 however once administrative tools become available to have more fine-grained control over what who can do what it can be used in in situations other than you've anticipated and used to set up a more secure network or system and we were aiming just to make it scale all the way from my mother using her iMac at home to corporate or a government institution that that needs a totally secure system and it's flexible and like I said before we're doing explicit you're making explicit access control decision rather than just doing it ad hoc so here's the recommended architecture for you writing an application the application is is your actual app with the GUI and whatnot the tool is the component of your application which will run with elevated privileges there are different ways to make that happen one of the ways is to have the installer install a set your ID root component so your application will launch the tool on demand when when it needs to perform a privileged operation now there's a third thing in this picture which is a security server and that's a process running on Mac OS 10 all the time which is essentially the part of the system that holds on to all these security sensitive information it's for example it's it's the basis for storing keys in the keychain it's and it's the basis for storing state for the authorization API as you'll see so first thing that happens is your application obtains authorization to perform a certain operation the security server will actually go out and do any necessary UI at this point so even if your application is not actually a GUI app but let's say it's a command-line tool or some other application we can still do UI for you if you passes the flag saying do whatever you eye is needed the security server actually launches a separate process and does the UI there so it doesn't matter whether you're carbon or cocoa or whatever will present the UI in a consistent way to the user so now after you've obtained the authorization the security server remembers some state about the fact that you've gotten this authorization the next thing is you externalize that authorization and pass it from your application to your tool and there are a couple of different ways to do that and I'll show you that later then the tool which is a situating root program which means that anyone can execute it and potentially have it do something before it does anything at all the first thing it does is it checks the rights of the passing authorization to see if they allow what the tool has been asked to do by the application so even though your tool is actually running with elevated privileges it won't do anything unless unless the unless you've checked and made sure that what you've been asked to do is actually allowed and finally the tool performs the operation and you can launch the tool each time you do this or you can write a tool that keeps on running as long as your application runs there's there's different models for this so a little bit about what it does and doesn't do currently it's password based only using that info so that means that it uses users groups from that info and in you authenticate using a password just like when you log into Mac os10 it answers the do I have the right to do this question but it doesn't in and of itself grant access you still need you need to already be privileged and have the privileges to perform the operation it offers a Shinae piain of itself doesn't give you the privilege to do it but what it helps you do is determine whether or not you should do it so it lets you make tools that don't compromise system security and it's up to the administrator of the system whether that be you the owner or or some actual administrator in a lab to determine who can do what rather than you having to make that decision as the application developer so just to make this clear Mac os10 is not a capability based operating system there aren't really any capability based commercial operating systems out there today it would be really cool to have that which would basically mean that in asking for the right to do something you would now also be able to do it unfortunately that's not something the kernel and the whole UNIX environment supports today there is some work going on in that in in the open source community and in other communities so maybe a couple years down the road we will have that just today the authorization API lets you solve this problem by splitting your app into two components and finally we provide user interaction when necessary so you don't have to go and program the UI for getting all this information etc one thing I do want to say is that even though today it's password based only we are looking into making the backend for the authorization API pluggable which means we might support other forms of authentication in the future think of smart card based or biometrics and whatnot and when that happens your applications won't have to change which means if you're using the authorization API today and those things get added to the system if an administrator configures it that you need a smart part to reboot your server then that automatically happens without you or needle hard to access the administration interface of your database engine or whatever it is that you wrote that will happen without you having to rub your product so a little bit about the API itself the first thing the naming of rights authorization API works with things called brights basically you ask for the right to perform a certain operation and a right is really nothing more than a string a C string we we have some proposed naming for writes of course we we we list a number of Rights that we internally use in the system but we can't predict which rights your application would want to use I mean an example of a right might be comm dot my company dot initialized database which we can't predict what kind of operations you want to perform authorization for so you get to make up those names for rights we'll give you some guidelines and what they should look like talk a little bit about how the application communication that you saw in that in that previous fancy-looking slide will work at the API level and some recommended usage of the API itself and finally I'll finish off with the temporary and I want to stress that temporary solution for third-party installers for those of you that are familiar with the authorization API there are some articles out in the web right now and how to use it and they're actually using the API we intended to be for third-party installers as the means to gain root access and it's there and it's it's going to stay there it's just that we want to streamline the other parts of the API more so that in most cases you won't even see a dialog your users won't see a dialog the that particular API we're not going to get away from having a dialog because it's basically giving root access to an arbitrary program so we really want to have the user confirm that in all cases so naming of rights right sir are mapped into a hierarchical namespace sort of like DNS like with dots we define like different high level domains but like I said we don't define each individual rights since the needs of each application are different and some example of write names that we currently use would be system data logon console which is the ability to log on in in login window system that logon does remote would be the ability to log on let's say through telnet you could further qualify that let's say systems are long in remote telnet system that long and remote dot our login etc one of the things we allow in the configuration is is wildcard matching on on prefixes of write names so that means if you choose your hierarchy of names you might want to think of it and you might want to name writes in a way that if someone puts some prefix star it actually makes sense for your application so that you you'd find qualify the details towards the end of the name we explicitly didn't want to allow for like arbitrary regular expressions of write names in in the rules configuration because if we do that it's going to be very unclear which rule gets matched in certain situations for an administrator so we want to try and keep it simple so that someone administering this can actually understand what's going to happen in a particular situation and there's some others here one that's the particularly noticeable one is the system privilege admin which is the right that gives you the ability to run an arbitrary processes of route using the API for installers so like I said before application communication one of the things that enables you to do is to split off and I can't stress this enough is to split off the security sensitive operations into small well understood tools that are auditable that you that don't depend on like the entire OS ten stack and don't depend on core graphics and whatnot an app kit and carbon so that the amount of code running with elevated privileges as little as possible and you actually know what's going on there and to do that would provide api's to pass authorization tokens between processes so there's a slight something I didn't mention before the slight difference between authorization and pre-authorization and that's when an application asks for authorization in the original first step it would be lets say you present a button that says press this button to unlock the UI so you can make changes to the administrator whatever that's called pre-authorization at that point you're asking for permission to do something in the future but you're not actually doing it at this point when you actually go off in your tool and perform the operation you're doing an actual authorization and the reason we want to make that distinction is that certain operations might be so sensitive that we don't that an administrator doesn't want to allow them to be pre authorized which means when you do the pre authorization you'll get an answer back saying yes you can do this but we can't confirm it until until later until you actually go and do it to in in Mac OS 10 today whenever you ask for a right in the current configuration things can be pre authorized and your authorization stays valid for five minutes which basically means if you go into one app and authorize to a panel they're using admin privileges you go to a different app you're still authorized for the next five minutes which we chose to do this it's a slight balance between security and usability it means that the OS 9 user after you login if you go directly to System Preferences and make some changes you're still authorized five minutes later you're not you'd be asked for your password again it also means if you go fifteen different panels that's all have different rights you don't have to type your password fifteen different times if you're changing them all at once of course in more security sensitive environments people might want to type tighten that down which we allow for it's just that the decision whether or not that happens actually happens in the configuration rather than in your application so if you're alarmed about this happening today and you might want to think about trying to tie that down we recommend you not do that because we really want to have the administrator be able to control how that works rather than the application developers so the first the first thing that happens is that with the pre-authorization I should probably skip to the next slide and come back to this later so I'll get back to this one in a sec first thing that happens when you're using the authorization API is you create an authorization Ref which is basically a handle to the security server that represents the rights you have you can create an authorization Ref and figure out what's currently allowed by using copyrights the way you'd use copyrights is you ask for all the right you list all the rights that you might potentially be interested in having and figure out which of them are currently allowed since like I said before we have this notion of this 5-minute timeout by default it could be that when your app gets launched it's already allowed to do everything you would possibly ever want to do in which case you show your UI unlocked and show all the fields editable if it's not you can lock down the UI and when the user wants to make changes by clicking a button or some other whatever you I you want to use for that I mean traditionally I was 10 uses a little press to the lock button to make changes here so that's probably what you should do if you want to be consistent you perform a pre-authorization using copyrights which pre-authorization basically just means you're passing an extra flag to copyright saying please do a pre-authorization instead of a regular one and you ask for the same rights again the only difference is this time you say and do any UI that's needed to get these rights in which case we'll go off do the UI and extend whatever rights you have to match what you're asking for if you if your application is willing to deal with only getting part of the rights that you need you can pass a flag for that and you'd have to check the return rights to see which of the ones you've asked for actually come in if you want all they're nothing you just don't ask for partial rights and will fail if you don't get everything you asked for then you can pass that authorization ref to your privilege tool or demon by calling authorization externalize or create external form I think is that the guys call and then we get to the tool which so you pass that ref to your tool preferably through any method other than the environment or command-line arguments since both of those can actually be snooping PS so you want to pass it out through pipe or using CF messages or mock IPC or whatever communication mecha there's a number of different communication mechanisms available on OS 10 we just recommend you not do it through the environment the UNIX environment or the command-line so then your tool calls create from external to basically create the authorization ref which is essentially the same one as in the application and then it calls copyrights to determine whether the write that is needed to do what it needs to do has been granted when it's doing that it can also pass in the flag saying and do any UI that's needed to really have this happen which means that even though your tool is in the cocoa or carbon or whatever app will still go off and do whatever you eye is needed to make the actual operation happen which the reason we want you to do that is if if for some reason a particular operation can't be pre-authorized the UI won't actually happen until you get so if you don't pass that flag in certain setups the operation might fail and then you perform the requested operations if copyright says you can so just coming back to this slide the the pre-authorization again you do the pre-authorization it's my my croissant you do the pre-authorization in the app but not in the tool and so one of the other reasons we want you to have the pre-authorization is to keep the final call to copyrights as close as possible to the operation so you make the call thing this is what I'm going to do it and then do it this also allows us to add audit logging to the authorization system in the future which means we could actually track what things have actually been done on the system which rights have been granted to which processes and so that you could later go back and look and see who's done what to your computer and it allows for a zero length timeout which essentially means that you have to enter the password or whatever authentication is needed to perform this right exactly when it happens rather than having it be valid for the next five minutes and for example removable tokens like smart cards and things like that in the future so strange title for this slide but this is what the UI currently looks like that we present this is actually directory setup I don't know if any of you been to that session so it presents it presents a dialog that with the text telling the user you need to enter administrator name and password to make changes in directory setup one of the things we'd like to have some feedback on is ways to improve this I know that there's there's been some comments from people where you would like to have the UI be more custom to your application and during the QA we can we can go over some of those things one of the issues we have we don't want to have it be possible for the application to mislead the user in what he's really granting access to so there needs to be balanced between how much can be customized so right now we actually hint the user name of the of the current user that's logged in if he would be performed to perform that operation and like I said we're looking into ways to making all of this pluggable which means you actually as a plugin developer be able to provide your own completely custom UI that says put your finger on the fingerprint reader or enter your magic passphrase now or whatever or speak your speak your name so finally is the temporary solution for third-party installers and that's the API is called authorization execute with privileges the write required to use that is system dot privilege dot admin so basically you need to create an authorization Ref that grants the right system dot privilege not admin and then you can call system the call authorization execute with privileges now this is a way to sort of work around the problem of having to be installed set your ID root and whatnot and just launch your tool with root privileges however depending on what the write is that your tool was needing to do let's say if it's a web server and all its really doing is binding to port 80 we can configure it in such a way that be asking for the right to bind to port 80 you really doesn't do any UI at all in the common case because it's like well my mother launches her personal web sharing why should she have to enter an admin password if you're using this API we're always going to do you.why so we're really because basically we're letting you execute an arbitrary binary with root privileges and this is currently the only way to do it on OS 10 but other than going through sudo on the command line so it's it's there but we really like you to use the authorization API as I've talked about the rest of the session rather than just shortcut everything and use this API so as a summary rights are not capabilities rights are our things that you ask for a right to do something having that right doesn't actually let you do it yet you still need to actually have those privileges in the first place to be able to perform the operation so like I said before what we do is help you make the decision of should I do this on behalf of the user your application should not run with root privileges you should you want to split that off into the separate tool and you want to pre authorize the rights and then pass them to the tool and then actually do the operation and finally keep the privileged tool as small as possible and audit it I can't stress this enough I mean any of you familiar with with UNIX or Linux know that anything that's set you're a tea brewed or anything that even isn't set ready root but you run using authorization execute with privileges needs to be very carefully examined because any potential security hole in that can compromise the whole system so here are some resources to go look at there's a developer page the CDSA spec all of our security work that we've been doing the last two years is based on CGS a 2.0 which is an open group standard and all of the work CDSA and below actually even up to the authorization api is is now open source and is available on the CVS open source apple comm server and you can follow the PCC links for the smart card access stuff so there's a number of related sessions there's a security overview that you're already missed and there's a kerberos session later this week and actually there's also a keychain session right after this session which is well worth attending if you're interested in security and then finally there's the feedback forum so any questions that you can't get answered today you can all come to the feedback forum and and talk about it there and Craig that was here before me is the person to contact with any technical or developer questions related to this and he'll make sure it gets forwarded to the appropriate people in our team you