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