Using the security framework

  • Hello!

    I am making a hard drive cloner/backuper, and to do some deleting and
    copying, I need to use the security framework. What I need to be able
    to do is have the user type in their password one time, and then it
    would give me system.privilege.admin rights until a time that they
    want to unauthorized it (could be days, weeks, months, years). I have
    looked through the security framework, but have not really found how
    to have one system.privilege.admin authorization, and have it last a
    long time. So, if anyone could point me in the right direction with
    this, like what methods to use, and what parameters to use.

    I'm also wondering another thing. To delete the files, I need admin
    privileges, but, do I need to create a new target (e.g. a shell
    script) to do the copying and then run the command (blanking on the
    name) that runs the script at a given path with admin privileges. Or,
    could I somehow use NSFileManager in an authorized state.

    Thanks for any help!

    Joe
  • On Jan 3, 2009, at 6:50 PM, Joe Turner wrote:

    > I am making a hard drive cloner/backuper, and to do some deleting
    > and copying, I need to use the security framework. What I need to be
    > able to do is have the user type in their password one time, and
    > then it would give me system.privilege.admin rights until a time
    > that they want to unauthorized it (could be days, weeks, months,
    > years). I have looked through the security framework, but have not
    > really found how to have one system.privilege.admin authorization,
    > and have it last a long time. So, if anyone could point me in the
    > right direction with this, like what methods to use, and what
    > parameters to use.

    If you pre-authorize an admin authorization, then it will last for 300
    seconds and then must be renewed. This is not something you can
    programmatically change; it's set in the computer's /etc/authorization
    file.

    > I'm also wondering another thing. To delete the files, I need admin
    > privileges, but, do I need to create a new target (e.g. a shell
    > script) to do the copying and then run the command (blanking on the
    > name) that runs the script at a given path with admin privileges.
    > Or, could I somehow use NSFileManager in an authorized state.

    You have to have something else do the work, since the security model
    of Mac OS X (and all Unix-like OSes) do not allow the escalation of
    privileges in an existing task.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • At 18:50 -0600 3/1/09, Joe Turner wrote:
    > I am making a hard drive cloner/backuper, and to do some deleting
    > and copying, I need to use the security framework. What I need to be
    > able to do is have the user type in their password one time, and
    > then it would give me system.privilege.admin rights until a time
    > that they want to unauthorized it (could be days, weeks, months,
    > years). I have looked through the security framework, but have not
    > really found how to have one system.privilege.admin authorization,
    > and have it last a long time. So, if anyone could point me in the
    > right direction with this, like what methods to use, and what
    > parameters to use.

    One way to do this is to have a second tool that runs as root.  You
    need to ask for admin permissions the first time to enable suid mode
    on the tool, but after that the tool will run as root with full
    privileges.

    Naturally, this has all the inherent security implications of that of
    any suid root tool, and the tool must now defend against possible
    misuse.  Some security suggestions include:

    * Code sign both your application and your tool and verify both
    signatures before applying the suid bit.

    * Strictly limit the actions of the tool.

    * Ensure requests to the tool are processed only if they come from
    your properly signed application.

    * Strictly minimize the tools code to minimize the chance of security
    related bugs.

    * Limit the use of external frameworks in the tool to minimize the
    chance of security issues.

    Enjoy,
        Peter.

    --
                  Keyboard Maestro 3 Now Available!
        Now run macros from your iPhone with Keyboard Maestro Control!

    Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your Mac
    <>          <<A href="http://download.stairways.com/">http://download.stairways.com/>
  • On 07/01/2009 05:36, "Peter N Lewis" <peter...> wrote:

    > At 18:50 -0600 3/1/09, Joe Turner wrote:
    >> I am making a hard drive cloner/backuper, and to do some deleting
    >> and copying, I need to use the security framework. What I need to be
    >> able to do is have the user type in their password one time, and
    >> then it would give me system.privilege.admin rights until a time
    >> that they want to unauthorized it (could be days, weeks, months,
    >> years). I have looked through the security framework, but have not
    >> really found how to have one system.privilege.admin authorization,
    >> and have it last a long time. So, if anyone could point me in the
    >> right direction with this, like what methods to use, and what
    >> parameters to use.
    >
    > One way to do this is to have a second tool that runs as root.  You
    > need to ask for admin permissions the first time to enable suid mode
    > on the tool, but after that the tool will run as root with full
    > privileges.
    >
    > Naturally, this has all the inherent security implications of that of
    > any suid root tool, and the tool must now defend against possible
    > misuse.  Some security suggestions include:
    >

    To avoid some of the problems with using a setuid tool, you can use launchd
    to run the privileged process as root. See the B.A.S. readme:
    http://developer.apple.com/samplecode/BetterAuthorizationSample/listing4.ht
    m

    l

    > * Code sign both your application and your tool and verify both
    > signatures before applying the suid bit.
    >
    > * Strictly limit the actions of the tool.
    >
    > * Ensure requests to the tool are processed only if they come from
    > your properly signed application.
    >
    > * Strictly minimize the tools code to minimize the chance of security
    > related bugs.
    >
    > * Limit the use of external frameworks in the tool to minimize the
    > chance of security issues.
    >

    These are still all good ideas. Another thing to do is to convert the Auth
    Services rights structure into an external form, and pass it to the helper -
    the helper then only performs privileged operations if it agrees that it has
    received the authorisation.

    Cheers,
    Graham.

    --
    Graham Lee
    Senior Macintosh Software Engineer, Sophos Plc.
    +44 1235 540266
    http://www.sophos.com/

    Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
    Company Reg No 2096520. VAT Reg No GB 348 3873 20.
  • On Jan 6, 2009, at 10:45 AM, Nick Zitzmann wrote:

    >
    > On Jan 3, 2009, at 6:50 PM, Joe Turner wrote:
    >
    >> I am making a hard drive cloner/backuper, and to do some deleting
    >> and copying, I need to use the security framework. What I need to
    >> be able to do is have the user type in their password one time, and
    >> then it would give me system.privilege.admin rights until a time
    >> that they want to unauthorized it (could be days, weeks, months,
    >> years). I have looked through the security framework, but have not
    >> really found how to have one system.privilege.admin authorization,
    >> and have it last a long time. So, if anyone could point me in the
    >> right direction with this, like what methods to use, and what
    >> parameters to use.
    >
    > If you pre-authorize an admin authorization, then it will last for
    > 300 seconds and then must be renewed. This is not something you can
    > programmatically change; it's set in the computer's /etc/
    > authorization file.

    That makes sense, but then how does an app like SuperDuper! do it. You
    click the lock, enter your password, and then you don't need to enter
    your password again until you lock it again. And, it is the regular
    security framework password window, so the developer must be doing
    some sort of authorization that lasts forever. And I checked, it does
    authorize system.privilege.admin.
    >
    >
    >> I'm also wondering another thing. To delete the files, I need admin
    >> privileges, but, do I need to create a new target (e.g. a shell
    >> script) to do the copying and then run the command (blanking on the
    >> name) that runs the script at a given path with admin privileges.
    >> Or, could I somehow use NSFileManager in an authorized state.
    >
    >
    > You have to have something else do the work, since the security
    > model of Mac OS X (and all Unix-like OSes) do not allow the
    > escalation of privileges in an existing task.
    Makes sense. So, if I create a separate target for the unix script, do
    I need to add something to it that takes the authorization? Or will
    anything it does that uses admin files be allowed?

    Thanks a lot!

    Joe
    >
    >
    > Nick Zitzmann
    > <http://www.chronosnet.com/>
    >
    >
    >
  • On 20/01/2009, at 12:56 PM, Joe Turner wrote:

    > That makes sense, but then how does an app like SuperDuper! do it.
    > You click the lock, enter your password, and then you don't need to
    > enter your password again until you lock it again. And, it is the
    > regular security framework password window, so the developer must be
    > doing some sort of authorization that lasts forever. And I checked,
    > it does authorize system.privilege.admin.

    The padlock is an SFAuthorizationView and it handles some of this,
    although I've not used it myself.

    --
    Rob Keniger
  • On Jan 19, 2009, at 7:56 PM, Joe Turner wrote:

    > That makes sense, but then how does an app like SuperDuper! do it.
    > You click the lock, enter your password, and then you don't need to
    > enter your password again until you lock it again. And, it is the
    > regular security framework password window, so the developer must be
    > doing some sort of authorization that lasts forever. And I checked,
    > it does authorize system.privilege.admin.

    There is no authorization that lasts forever. Either it's polling to
    keep the authorization alive (which may theoretically work, though
    I've never tried it), or it forgot to set the authorization view to
    auto-refresh the authorization status (which I think has to be done in
    code).

    > Makes sense. So, if I create a separate target for the unix script,

    I wouldn't really recommend running shell code with root privileges as
    a user other than root. That can be a security hole waiting to happen,
    since changes to the user's environment will affect the script. AEWP()
    executes things with root privileges, but not _as_ root (so it'll be
    executed as the user). There are workarounds to this, but the best
    workaround is to just avoid this if at all possible.

    > do I need to add something to it that takes the authorization? Or
    > will anything it does that uses admin files be allowed?

    Once you run something with AEWP(), it has root privileges.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • Thanks again for the speedy responses!

    On Jan 20, 2009, at 1:47 AM, Nick Zitzmann wrote:

    >
    > On Jan 19, 2009, at 7:56 PM, Joe Turner wrote:
    >
    >> That makes sense, but then how does an app like SuperDuper! do it.
    >> You click the lock, enter your password, and then you don't need to
    >> enter your password again until you lock it again. And, it is the
    >> regular security framework password window, so the developer must
    >> be doing some sort of authorization that lasts forever. And I
    >> checked, it does authorize system.privilege.admin.
    >
    >
    > There is no authorization that lasts forever. Either it's polling to
    > keep the authorization alive (which may theoretically work, though
    > I've never tried it), or it forgot to set the authorization view to
    > auto-refresh the authorization status (which I think has to be done
    > in code).

    I see. Then, how would you suggest to create a cloner/deleter, if it
    needs root privileges, but cannot use the security framework?

    What I did a bit ago was, from the command line (NSTask) call a sudu
    and then run ditto or rsync, and used a pipe to give it the password.
    I had a custom password view where the user entered their password.
    The only thing is, I am trying to make external shell scripts
    unneeded, which is why I originally just wanted to use NSFileManager.

    And, since running scripts from root is dangerous, then is there any
    good way to be able to delete protected (not your user account) files?
    Or, should I just have it copy or delete files the user has access to?
    Or is there a way other than the security framework to delete  files
    the user does not have access to.

    Thank you again for all your help!

    Cheers,

    Joe Turner
    >
    >
    >> Makes sense. So, if I create a separate target for the unix script,
    >
    > I wouldn't really recommend running shell code with root privileges
    > as a user other than root. That can be a security hole waiting to
    > happen, since changes to the user's environment will affect the
    > script. AEWP() executes things with root privileges, but not _as_
    > root (so it'll be executed as the user). There are workarounds to
    > this, but the best workaround is to just avoid this if at all
    > possible.
    >
    >> do I need to add something to it that takes the authorization? Or
    >> will anything it does that uses admin files be allowed?
    >
    > Once you run something with AEWP(), it has root privileges.
    >
    > Nick Zitzmann
    > <http://www.chronosnet.com/>
    >
    >
    >
  • On Jan 22, 2009, at 4:09 PM, Joe Turner wrote:

    > I see. Then, how would you suggest to create a cloner/deleter, if it
    > needs root privileges, but cannot use the security framework?

    I didn't say you couldn't use the security framework. I said you ought
    to consider re-thinking your strategy.

    > And, since running scripts from root is dangerous, then is there any
    > good way to be able to delete protected (not your user account)
    > files? Or, should I just have it copy or delete files the user has
    > access to?

    There's nothing wrong with running scripts strictly as root, since a
    lot of system scripts are run this way. But AEWP() doesn't run
    executables as root; it runs them as the user with root privileges.
    There's an important difference.

    Instead of running a shell script, run another non-GUI command line
    tool of your making with AEWP() that does the required privileged task
    (s). Running shell code with root privileges as some user is possible,
    but it's an easy attack vector due to the inheritance of the user's
    shell environment. Running a command line tool is a bit more difficult
    to hack (but still possible if someone is determined enough). Plus,
    then you can use NSFileManager. :)

    You could even take security to the extreme, as I once did in an
    application, and check signatures before calling AEWP(), but that's
    probably too extreme, as it's unlikely someone will rewrite or replace
    your executable unless the file system gave them permission to do so.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • On Jan 22, 2009, at 4:57 PM, Nick Zitzmann wrote:

    >
    > On Jan 22, 2009, at 4:09 PM, Joe Turner wrote:
    >
    >> I see. Then, how would you suggest to create a cloner/deleter, if
    >> it needs root privileges, but cannot use the security framework?
    >
    > I didn't say you couldn't use the security framework. I said you
    > ought to consider re-thinking your strategy.
    >
    >> And, since running scripts from root is dangerous, then is there
    >> any good way to be able to delete protected (not your user account)
    >> files? Or, should I just have it copy or delete files the user has
    >> access to?
    >
    >
    > There's nothing wrong with running scripts strictly as root, since a
    > lot of system scripts are run this way. But AEWP() doesn't run
    > executables as root; it runs them as the user with root privileges.
    > There's an important difference.
    >
    > Instead of running a shell script, run another non-GUI command line
    > tool of your making with AEWP() that does the required privileged
    > task(s). Running shell code with root privileges as some user is
    > possible, but it's an easy attack vector due to the inheritance of
    > the user's shell environment. Running a command line tool is a bit
    > more difficult to hack (but still possible if someone is determined
    > enough). Plus, then you can use NSFileManager. :)
    >
    > You could even take security to the extreme, as I once did in an
    > application, and check signatures before calling AEWP(), but that's
    > probably too extreme, as it's unlikely someone will rewrite or
    > replace your executable unless the file system gave them permission
    > to do so.

    Okay, I guess I should just put scheduling without needing the
    password to the back of my queue.

    I have one more question (sorry for all of these questions): If I call
    AuthorizationCopyRights() every 280 (or anything less than 300 secs)
    during the clone, will it keep the authorization alive (no need to
    enter password again)?

    Thanks for all your help–You have no idea how much it means to me :)

    Cheers,

    Joe Turner
    >
    >
    > Nick Zitzmann
    > <http://www.chronosnet.com/>
    >
    >
    >
  • On Thu, Jan 22, 2009 at 10:15 PM, Joe Turner <joeturner...> wrote:
    >
    > On Jan 22, 2009, at 4:57 PM, Nick Zitzmann wrote:
    >
    >>
    >> On Jan 22, 2009, at 4:09 PM, Joe Turner wrote:
    >>
    >>> I see. Then, how would you suggest to create a cloner/deleter, if it
    >>> needs root privileges, but cannot use the security framework?
    >>
    >> I didn't say you couldn't use the security framework. I said you ought to
    >> consider re-thinking your strategy.
    >>
    >>> And, since running scripts from root is dangerous, then is there any good
    >>> way to be able to delete protected (not your user account) files? Or, should
    >>> I just have it copy or delete files the user has access to?
    >>
    >>
    >> There's nothing wrong with running scripts strictly as root, since a lot
    >> of system scripts are run this way. But AEWP() doesn't run executables as
    >> root; it runs them as the user with root privileges. There's an important
    >> difference.
    >>
    >> Instead of running a shell script, run another non-GUI command line tool
    >> of your making with AEWP() that does the required privileged task(s).
    >> Running shell code with root privileges as some user is possible, but it's
    >> an easy attack vector due to the inheritance of the user's shell
    >> environment. Running a command line tool is a bit more difficult to hack
    >> (but still possible if someone is determined enough). Plus, then you can use
    >> NSFileManager. :)
    >>
    >> You could even take security to the extreme, as I once did in an
    >> application, and check signatures before calling AEWP(), but that's probably
    >> too extreme, as it's unlikely someone will rewrite or replace your
    >> executable unless the file system gave them permission to do so.
    >
    > Okay, I guess I should just put scheduling without needing the password to
    > the back of my queue.
    >
    > I have one more question (sorry for all of these questions): If I call
    > AuthorizationCopyRights() every 280 (or anything less than 300 secs) during
    > the clone, will it keep the authorization alive (no need to enter password
    > again)?

    Don't do that. The standard way to accomplish a permanent unlock that
    you're talking about is (I think) to have a suid root tool. You use
    AEWP to run it as root so that it can become suid root, and after that
    it simply *stays* suid root, as that's a filesystem property that
    won't be disappearing spontaneously. As long as it's suid root you
    don't need to touch AEWP again.

    Of course you need to securely control access to your suid root tool
    in that case, and I don't recall exactly how you do this, but I
    believe the authorization APIs allow you to generate tokens that you
    can pass to the tool to be checked for validity so that not just
    anyone can come in and use the tool. And I'm pretty sure that Apple
    has sample code to illustrate this. Definitely look at that sample
    code no matter what; these APIs are ridiculously difficult to get
    right, and you don't want to be working with them without a concrete
    example sitting in front of you that you can crib from.

    Mike
  • On 23 Jan 2009, at 05:05, Michael Ash wrote:

    > On Thu, Jan 22, 2009 at 10:15 PM, Joe Turner <joeturner...> wrote:
    >>
    >> On Jan 22, 2009, at 4:57 PM, Nick Zitzmann wrote:
    >>
    >>>
    >>> On Jan 22, 2009, at 4:09 PM, Joe Turner wrote:
    >>>
    >>>> I see. Then, how would you suggest to create a cloner/deleter, if
    >>>> it
    >>>> needs root privileges, but cannot use the security framework?
    >>>
    >>> I didn't say you couldn't use the security framework. I said you
    >>> ought to
    >>> consider re-thinking your strategy.
    >>>
    >>>> And, since running scripts from root is dangerous, then is there
    >>>> any good
    >>>> way to be able to delete protected (not your user account) files?
    >>>> Or, should
    >>>> I just have it copy or delete files the user has access to?
    >>>
    >>>
    >>> There's nothing wrong with running scripts strictly as root, since
    >>> a lot
    >>> of system scripts are run this way. But AEWP() doesn't run
    >>> executables as
    >>> root; it runs them as the user with root privileges. There's an
    >>> important
    >>> difference.
    >>>
    >>> Instead of running a shell script, run another non-GUI command
    >>> line tool
    >>> of your making with AEWP() that does the required privileged
    >>> task(s).
    >>> Running shell code with root privileges as some user is possible,
    >>> but it's
    >>> an easy attack vector due to the inheritance of the user's shell
    >>> environment. Running a command line tool is a bit more difficult
    >>> to hack
    >>> (but still possible if someone is determined enough). Plus, then
    >>> you can use
    >>> NSFileManager. :)
    >>>
    >>> You could even take security to the extreme, as I once did in an
    >>> application, and check signatures before calling AEWP(), but
    >>> that's probably
    >>> too extreme, as it's unlikely someone will rewrite or replace your
    >>> executable unless the file system gave them permission to do so.
    >>
    >> Okay, I guess I should just put scheduling without needing the
    >> password to
    >> the back of my queue.
    >>
    >> I have one more question (sorry for all of these questions): If I
    >> call
    >> AuthorizationCopyRights() every 280 (or anything less than 300
    >> secs) during
    >> the clone, will it keep the authorization alive (no need to enter
    >> password
    >> again)?
    >
    > Don't do that. The standard way to accomplish a permanent unlock that
    > you're talking about is (I think) to have a suid root tool. You use
    > AEWP to run it as root so that it can become suid root, and after that
    > it simply *stays* suid root, as that's a filesystem property that
    > won't be disappearing spontaneously. As long as it's suid root you
    > don't need to touch AEWP again.
    >
    > Of course you need to securely control access to your suid root tool
    > in that case, and I don't recall exactly how you do this, but I
    > believe the authorization APIs allow you to generate tokens that you
    > can pass to the tool to be checked for validity so that not just
    > anyone can come in and use the tool. And I'm pretty sure that Apple
    > has sample code to illustrate this. Definitely look at that sample
    > code no matter what; these APIs are ridiculously difficult to get
    > right, and you don't want to be working with them without a concrete
    > example sitting in front of you that you can crib from.
    >
    Another source of info on this would be Dalrymple + Hillegass -
    Advanced Mac OS X Programming.
    It doesn't seem to be searchable on the web so you will need the
    physical papery object.

    Chapter 17 covers the whole SUID/ticket business in detail (21 pages )
    with a working example.

    > Mike

    Jonathan Mitchell

    Central Conscious Unit
    http://www.mugginsoft.com
  • Okay, so, it seems everyone was right :) I went to cocoabuilder to
    find some of the responses to this, that I never got.

    Anyways, it seems I can just call AEWP() once, and it should stay suid.

    So, my last question to everyone is, how do I know if the tool is
    suid. I mean, I could implement some sort of lock-unlock thing, and
    then I would be pretty sure, but is there anyway to know for sure?

    And, is there a way to take SUID away from it? So, if I want to lock
    it, it would work.

    Thanks everyone!

    Cheers,

    Joe Turner
    On Jan 22, 2009, at 4:57 PM, Nick Zitzmann wrote:

    >
    > On Jan 22, 2009, at 4:09 PM, Joe Turner wrote:
    >
    >> I see. Then, how would you suggest to create a cloner/deleter, if
    >> it needs root privileges, but cannot use the security framework?
    >
    > I didn't say you couldn't use the security framework. I said you
    > ought to consider re-thinking your strategy.
    >
    >> And, since running scripts from root is dangerous, then is there
    >> any good way to be able to delete protected (not your user account)
    >> files? Or, should I just have it copy or delete files the user has
    >> access to?
    >
    >
    > There's nothing wrong with running scripts strictly as root, since a
    > lot of system scripts are run this way. But AEWP() doesn't run
    > executables as root; it runs them as the user with root privileges.
    > There's an important difference.
    >
    > Instead of running a shell script, run another non-GUI command line
    > tool of your making with AEWP() that does the required privileged
    > task(s). Running shell code with root privileges as some user is
    > possible, but it's an easy attack vector due to the inheritance of
    > the user's shell environment. Running a command line tool is a bit
    > more difficult to hack (but still possible if someone is determined
    > enough). Plus, then you can use NSFileManager. :)
    >
    > You could even take security to the extreme, as I once did in an
    > application, and check signatures before calling AEWP(), but that's
    > probably too extreme, as it's unlikely someone will rewrite or
    > replace your executable unless the file system gave them permission
    > to do so.
    >
    > Nick Zitzmann
    > <http://www.chronosnet.com/>
    >
    >
    >
  • On Fri, Jan 23, 2009 at 10:59 PM, Joe Turner <joeturner...> wrote:
    > Okay, so, it seems everyone was right :) I went to cocoabuilder to find some
    > of the responses to this, that I never got.
    >
    > Anyways, it seems I can just call AEWP() once, and it should stay suid.
    >
    > So, my last question to everyone is, how do I know if the tool is suid. I
    > mean, I could implement some sort of lock-unlock thing, and then I would be
    > pretty sure, but is there anyway to know for sure?
    >
    > And, is there a way to take SUID away from it? So, if I want to lock it, it
    > would work.

    "man 2 stat" to check the bit, "man 2 chmod" to set it.

    Mike
  • Cool, thanks!

    Then I now have another question: Why not just run chmod on my utility
    when it's 'unlocked', and change the userID to 0. Then when it's
    locked, change it back to 501?

    Or, is this exactly what AEWP() will do?

    Thanks!

    Cheers,

    Joe Turner
    On Jan 24, 2009, at 6:47 AM, Michael Ash wrote:

    > On Fri, Jan 23, 2009 at 10:59 PM, Joe Turner <joeturner...> wrote:
    >> Okay, so, it seems everyone was right :) I went to cocoabuilder to
    >> find some
    >> of the responses to this, that I never got.
    >>
    >> Anyways, it seems I can just call AEWP() once, and it should stay
    >> suid.
    >>
    >> So, my last question to everyone is, how do I know if the tool is
    >> suid. I
    >> mean, I could implement some sort of lock-unlock thing, and then I
    >> would be
    >> pretty sure, but is there anyway to know for sure?
    >>
    >> And, is there a way to take SUID away from it? So, if I want to
    >> lock it, it
    >> would work.
    >
    > "man 2 stat" to check the bit, "man 2 chmod" to set it.
    >
    > Mike
  • I think I figured out how SD does it:

    When you unlock SD!, it calls AEWP() on SDAgent. Then, SDAgent calls
    setuid(0) to make itself root. With it as root, when it calls SDCopy,
    or SDDiskTool, it calls it with AEWP, and since it's root, it doesn't
    need the user's password to do this!

    This is just my guess. But it sounds fairly right :)

    Cheers,

    Joe Turner
    On Jan 24, 2009, at 6:47 AM, Michael Ash wrote:

    > On Fri, Jan 23, 2009 at 10:59 PM, Joe Turner <joeturner...> wrote:
    >> Okay, so, it seems everyone was right :) I went to cocoabuilder to
    >> find some
    >> of the responses to this, that I never got.
    >>
    >> Anyways, it seems I can just call AEWP() once, and it should stay
    >> suid.
    >>
    >> So, my last question to everyone is, how do I know if the tool is
    >> suid. I
    >> mean, I could implement some sort of lock-unlock thing, and then I
    >> would be
    >> pretty sure, but is there anyway to know for sure?
    >>
    >> And, is there a way to take SUID away from it? So, if I want to
    >> lock it, it
    >> would work.
    >
    > "man 2 stat" to check the bit, "man 2 chmod" to set it.
    >
    > Mike
  • The proper way to construct everything you've described is discussed
    in the Authorization Services Programming Guide.

    Authorization Services Programming Guide
    http://developer.apple.com/documentation/Security/Conceptual/authorization_
    concepts/index.html


    The current, most up-to-date and correct example of constructing an
    application with a helper that performs privileged operations securely
    on its behalf is "BetterAuthorizationSample" which replaces the
    previous "MoreAuthSample" example code.

    BetterAuthorizationSample
    http://developer.apple.com/samplecode/BetterAuthorizationSample/index.html

    It is critical to your users' security that you understand everything
    presented in the above programming guide and example before you
    attempt to write code that needs to run with elevated privileges.  You
    must not simply use AuthorizationExecuteWithPrivileges to run
    arbitrary code or scripts "as root."  You must install your helper
    tool securely.  There's a lot to do if you want to run code with
    elevated privileges, and it must be done correctly; the rationale for
    the design recommended by the Programming Guide and
    BetterAuthorizationSample is documented in "Design and Implementation
    Rationale.txt" within the example:

    BetterAuthorizationSample - Design and Implementation Rationale
    http://developer.apple.com/samplecode/BetterAuthorizationSample/listing4.ht
    ml


    Unfortunately, when it comes to system security there's no "I'm just…"
    or "I simply want to…"  All i's must be dotted and all t's crossed, or
    you risk compromising your users' security.  Fortunately there's
    extensive documentation on how to manage the complexity involved, and
    you can provide a decent user experience if you do the cooking by the
    book.

      -- Chris
  • So, you are saying that I must create an install tool, that installs
    my utility that will run as root?
    On Jan 24, 2009, at 2:23 PM, Chris Hanson wrote:

    > The proper way to construct everything you've described is discussed
    > in the Authorization Services Programming Guide.
    >
    > Authorization Services Programming Guide
    > http://developer.apple.com/documentation/Security/Conceptual/authorization_
    concepts/index.html

    >
    > The current, most up-to-date and correct example of constructing an
    > application with a helper that performs privileged operations
    > securely on its behalf is "BetterAuthorizationSample" which replaces
    > the previous "MoreAuthSample" example code.
    >
    > BetterAuthorizationSample
    > http://developer.apple.com/samplecode/BetterAuthorizationSample/index.html
    >
    > It is critical to your users' security that you understand
    > everything presented in the above programming guide and example
    > before you attempt to write code that needs to run with elevated
    > privileges.  You must not simply use
    > AuthorizationExecuteWithPrivileges to run arbitrary code or scripts
    > "as root."  You must install your helper tool securely.  There's a
    > lot to do if you want to run code with elevated privileges, and it
    > must be done correctly; the rationale for the design recommended by
    > the Programming Guide and BetterAuthorizationSample is documented in
    > "Design and Implementation Rationale.txt" within the example:
    >
    > BetterAuthorizationSample - Design and Implementation Rationale
    > http://developer.apple.com/samplecode/BetterAuthorizationSample/listing4.ht
    ml

    >
    > Unfortunately, when it comes to system security there's no "I'm
    > just…" or "I simply want to…"  All i's must be dotted and all t's
    > crossed, or you risk compromising your users' security.  Fortunately
    > there's extensive documentation on how to manage the complexity
    > involved, and you can provide a decent user experience if you do the
    > cooking by the book.
    >
    > -- Chris
    >
  • On Jan 24, 2009, at 1:41 PM, Joe Turner wrote:

    > So, you are saying that I must create an install tool, that installs
    > my utility that will run as root?

    I am saying that, in order to maintain your users' system security,
    you must follow the guidance in the Authorization Services Programming
    Guide and BetterAuthorizationSample example code when implementing
    software that needs to run with elevated privileges.

    Among other things, to be truly secure you must use a secure
    installation mechanism.  Do not write your own install tool — it can't
    be made secure without itself being installed via a secure
    installation mechanism.  Instead, use Installer.app for your
    installations since it's included with the operating system and not
    modifiable with normal user privileges.

    You can still ship your application as a drag-install; for example,
    your application itself can include an installer package to do the
    actual installation of the tool it uses and its launchd plist, and
    open the package in Installer.app if the tool needs to be installed.

      -- Chris
  • On Sat, Jan 24, 2009 at 6:08 PM, Chris Hanson <cmh...> wrote:
    > Among other things, to be truly secure you must use a secure installation
    > mechanism.  Do not write your own install tool — it can't be made secure
    > without itself being installed via a secure installation mechanism.
    > Instead, use Installer.app for your installations since it's included with
    > the operating system and not modifiable with normal user privileges.

    I'm afraid I don't understand this advice. Could you explain what sort
    of vulnerability would exist in a custom install tool that would not
    exist when using Installer.app to install a custom package?

    Mike
  • On Jan 24, 2009, at 6:29 PM, Michael Ash wrote:

    > On Sat, Jan 24, 2009 at 6:08 PM, Chris Hanson <cmh...> wrote:
    >> Among other things, to be truly secure you must use a secure
    >> installation
    >> mechanism.  Do not write your own install tool — it can't be made
    >> secure
    >> without itself being installed via a secure installation mechanism.
    >> Instead, use Installer.app for your installations since it's
    >> included with
    >> the operating system and not modifiable with normal user privileges.
    >
    > I'm afraid I don't understand this advice. Could you explain what sort
    > of vulnerability would exist in a custom install tool that would not
    > exist when using Installer.app to install a custom package?

    Because Installer.app is installed by the operating system you can -
    if you've taken appropriate security measures to begin with - be
    reasonably certain that it hasn't been tampered with.

    When writing your own install tool, you have a bootstrapping problem:
    You will eventually need to have the user authorize some untrusted
    code to run as root - code that could have been modified behind the
    user's back.

    An installer package could also have been writable by the user, but
    modern packages can be signed so their integrity can be checked.

      -- Chris
  • But you can also code sign nowadays
    On Jan 24, 2009, at 11:54 PM, Chris Hanson wrote:

    > On Jan 24, 2009, at 6:29 PM, Michael Ash wrote:
    >
    >> On Sat, Jan 24, 2009 at 6:08 PM, Chris Hanson <cmh...> wrote:
    >>> Among other things, to be truly secure you must use a secure
    >>> installation
    >>> mechanism.  Do not write your own install tool — it can't be made
    >>> secure
    >>> without itself being installed via a secure installation mechanism.
    >>> Instead, use Installer.app for your installations since it's
    >>> included with
    >>> the operating system and not modifiable with normal user privileges.
    >>
    >> I'm afraid I don't understand this advice. Could you explain what
    >> sort
    >> of vulnerability would exist in a custom install tool that would not
    >> exist when using Installer.app to install a custom package?
    >
    > Because Installer.app is installed by the operating system you can -
    > if you've taken appropriate security measures to begin with - be
    > reasonably certain that it hasn't been tampered with.
    >
    > When writing your own install tool, you have a bootstrapping
    > problem:  You will eventually need to have the user authorize some
    > untrusted code to run as root - code that could have been modified
    > behind the user's back.
    >
    > An installer package could also have been writable by the user, but
    > modern packages can be signed so their integrity can be checked.
    >
    > -- Chris
  • On Sat, Jan 24, 2009 at 9:29 PM, Michael Ash <michael.ash...> wrote:
    > I'm afraid I don't understand this advice. Could you explain what sort
    > of vulnerability would exist in a custom install tool that would not
    > exist when using Installer.app to install a custom package?

    It's vulnerable to a timing flaw.  In order to securely install a
    helper tool, the installation process must run as root.  In order to
    securely install an installer that runs as root, the installer
    installer must run as root.  In order to...

    Installer.app solves this problem because it's preconfigured to be
    secure.  You can invoke it to do the privileged installation for you
    without opening yourself up to the possibility that in between copying
    the file and its later invocation that its contents have been changed.

    --Kyle Sluder
  • On Sun, Jan 25, 2009 at 12:54 AM, Chris Hanson <cmh...> wrote:
    > On Jan 24, 2009, at 6:29 PM, Michael Ash wrote:
    >
    >> On Sat, Jan 24, 2009 at 6:08 PM, Chris Hanson <cmh...> wrote:
    >>>
    >>> Among other things, to be truly secure you must use a secure installation
    >>> mechanism.  Do not write your own install tool — it can't be made secure
    >>> without itself being installed via a secure installation mechanism.
    >>> Instead, use Installer.app for your installations since it's included
    >>> with
    >>> the operating system and not modifiable with normal user privileges.
    >>
    >> I'm afraid I don't understand this advice. Could you explain what sort
    >> of vulnerability would exist in a custom install tool that would not
    >> exist when using Installer.app to install a custom package?
    >
    > Because Installer.app is installed by the operating system you can - if
    > you've taken appropriate security measures to begin with - be reasonably
    > certain that it hasn't been tampered with.
    >
    > When writing your own install tool, you have a bootstrapping problem:  You
    > will eventually need to have the user authorize some untrusted code to run
    > as root - code that could have been modified behind the user's back.
    >
    > An installer package could also have been writable by the user, but modern
    > packages can be signed so their integrity can be checked.

    So could a custom installer. It seems to me that the problem of
    protecting a custom installer and the problem of protecting a custom
    package being used with the system installer are equivalent. Is there
    a way that a custom binary can be tampered with that a custom .pkg is
    immune to?

    Mike
  • On Sun, Jan 25, 2009 at 3:19 AM, Kyle Sluder <kyle.sluder...> wrote:
    > On Sat, Jan 24, 2009 at 9:29 PM, Michael Ash <michael.ash...> wrote:
    >> I'm afraid I don't understand this advice. Could you explain what sort
    >> of vulnerability would exist in a custom install tool that would not
    >> exist when using Installer.app to install a custom package?
    >
    > It's vulnerable to a timing flaw.  In order to securely install a
    > helper tool, the installation process must run as root.  In order to
    > securely install an installer that runs as root, the installer
    > installer must run as root.  In order to...
    >
    > Installer.app solves this problem because it's preconfigured to be
    > secure.  You can invoke it to do the privileged installation for you
    > without opening yourself up to the possibility that in between copying
    > the file and its later invocation that its contents have been changed.

    Instead of opening yourself up to the possibility that the contents of
    the installer binary have been changed, you open yourself up to the
    possibility that the contents of the installer .pkg have been changed.
    Doesn't seem any better to me.

    Mike
previous month january 2009 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Go to today