Apple Event: May 7th at 7 am PT

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Installer priviliges

Yesterday, I installed PHP 5 on Mac OS X, using the package that is linked on the PHP homepage.
Today, I audited the /var/log/secure.log file and noticed that I couldn't find any logged event for the PHP installation. Normally, when the password is acquired, this should be logged there.
As I couldn't remember if I had to enter my password during the PHP installation, I removed the PHP folder (/usr/local/php5, if I remember correctly) and tried a reinstall, even after a reboot of the system. During the installation process, I was not asked for my password. However, when the installation is completed, the newly created PHP folder is owned by root:wheel (while its contents seem to belong to myuser:wheel)
Now I am really confused how this can happend. My account is the default account and thus a sudoer. I believed that changing the owner of a file or directory to root can only be done using the sudoer-priviledges and thus requiring a password. The MySQL-Installation, for example, requested my password.
Could someone please explain me this strange effect?

Posted on Jul 26, 2006 9:43 AM

Best reply

Michael Bradshaw

Level 5

4,155 points

Posted on Jul 26, 2006 10:48 AM

If any script runs as sudo - it gets logged to /private/var/log/system.log

If any process (including the installer) uses the Apple provided security framework that calls the keychain or the box we are familiar with - it gets logged to /private/var/log/secure.log

View in context

41 replies

Jul 27, 2006 1:03 PM in response to biovizier

Actually, I just made packages to replace
'/etc/sudoers', and install a "StartupItem",
installed using '/usr/sbin/installer', and everything
installed with correct permissions (ie. both tested,
and fully functional).

So the package you made installed without demanding your password and was able to overwrite /etc/sudoers? This is really bad, I think. Perhaps you could inform Apple on this, including the "malicious" package you crafted?

Jul 27, 2006 1:08 PM in response to Matt Broughton

Matt,

You've answered this here. 🙂

admin users are root on OSX client. There isn't a root user unless you go to specific lengths to enable it. This seems to match the message that the installer automatically escalated the privelages.

The only possible security ramification now would be if a non-admin user could change whatever list or property is used to sigify "admin" status.

Also - it might need to be made known better that by being an admin - sometimes root things will happen without the password dialog. I for sure was under the impression that the system wouldn't do "root-like" things for me unless it asked for a password....

biovizier

Level 5

7,925 points

Jul 27, 2006 1:32 PM in response to kullerhamPster

..." So the package you made installed without demanding your password and was able to overwrite /etc/sudoers?"...

That is correct - working from an "admin" account (10.4.7), no authentication was requested at all, exactly as you described for the PHP5 package. I even did a ' sudo -k' and manually locked the lock in "System Preferences" just to make sure there weren't any elevated rights floating around for that account before running the installer.

I would submit a bug report, except, I'm not sure where exactly the bug is. It may be scary in itself, but I had never used "PackageMaker.app" before today and was able to figure it out how to construct a potentially malicious package in about three minutes after reading Matt Broughton's description. The point is, I can say "hey look at this!" but I don't know the ins and outs of how the installer and the "authorization" framework should work to articulate the problem. I'll probably submit one anyway over the weekend (including the package is a good idea), but I think it would help if others did so as well.

Jul 27, 2006 2:17 PM in response to Michael Bradshaw

admin users are root on OSX client. There isn't a
root user unless you go to specific lengths to enable
it. This seems to match the message that the
installer automatically escalated the privelages.

As far as I understood it, the default admin user is not the root user but can get root privileges by providing his password (and only by providing his password).
For example, try to create a folder in /usr/local with "mkdir test" with your default admin user. It won't work as long as you don't use sudo (which asks for your password).

The only possible security ramification now would be
if a non-admin user could change whatever list or
property is used to sigify "admin" status.

I don't agree. Of course, an unprivileged user gaining admin- or root privileges would be worse. But an installer that is started from an admin (not root) account should not be able to do things that normally would require a password. And as mentioned above, normally you can't create a new folder in /usr/local, and you can't overwrite /etc/sudoers.

Also - it might need to be made known better that by
being an admin - sometimes root things will happen
without the password dialog.

I'm afraid I don't understand the part between the "-" of your sentence. Do you have an example for root things happening without asking for the password?

I for sure was under the
impression that the system wouldn't do "root-like"
things for me unless it asked for a password....

This is what I believed and what would be a "correct" behaviour, imo. Of course, there are system services running with higher privileges, perhaps the installer is one of them. But I think a user with only admin privileges should not be allowed to manipulate these services in a way like the one described here.

And one more general aspect on this: I think Apple's intention using a sudoer instead of a root account and a default user was to let the "normal" user do his daily work with the default account created after the OS X installation. The sudoer concept is, on the one hand, a way to confine the risk of damage, while, on the other, it allows easy system administration without the overhead of an higher privileged account.
This, of course, only works if the concept is implemented correctly and consistently. This is - in my opinion - not the case here.

Jul 27, 2006 2:22 PM in response to biovizier

I would submit a bug report, except, I'm not sure
where exactly the bug is. It may be scary in itself,
but I had never used "PackageMaker.app" before today
and was able to figure it out how to construct a
potentially malicious package in about three minutes
after reading Matt Broughton's description. The point
is, I can say "hey look at this!" but I don't know
the ins and outs of how the installer and the
"authorization" framework should work to articulate
the problem. I'll probably submit one anyway over the
weekend (including the package is a good idea), but I
think it would help if others did so as well.

I think submitting a bug report is a good idea in any case.
Imo, the problem description can be simplified to the fact that files and folders only writeable for root can be (over)written by the default admin user without explicitly gaining root privileges. It's up to the guys at Apple to descide if this is a bug or if we see a problem that doesn't exist (although I don't believe this).

biovizier

Level 5

7,925 points

Jul 28, 2006 3:36 PM in response to kullerhamPster

Just to update, this afternoon I copied a package onto my flash drive, walked over to the local computer store, and with their permission, successfully tested it on one of their demo machines (logged in as an "admin"). Plug in the drive, double-click, prepare to sit back, but before your butt has a chance to hit the chair, it's done. A bug report has been submitted.

Of course, nothing really changes - most people have been advising against routinely using an "admin" account anyway...

Jul 28, 2006 6:11 PM in response to biovizier

I also have an update of sorts. I got thinking about privileges in the Installer and what happens when. I put together three sample packages representing the three levels of authorization available when building a package -- NoAuthorization; AdminAuthorization; and RootAuthorization. I have posted the scripts for download. Give them a try if you want.

The payload is quite simple. They each install a directory /usr/local/hello (root:wheel) with one file inside /usr/local/hello/world (userid502:wheel). I also included InstallationCheck, preflight, and postflight scripts. The main purpose of these scripts is to run the command 'whoami'. I had each script log the user they were running under to the install log. The InstallationCheck would not write to the log, so I included an AppleScript (osascript) display dialog for each of the script that also gives you the result of 'whoami'.

The quick run down is that the NoAuthorizaion package worked as expected. The scripts were run as the current user and the payload would not install. The RootAuthorization package also behaved as expected with scripts running as root after proper authentication. The AdminAuthorization package ran the Installation check as the current user. The preflight and postflight scripts were run as root. Yikes! A package that has only AdminAuthorization will run scripts as root and install a payload in a directory where only root is supposed to have write privileges.

Having discovered that, I raised the ante a bit and had the postflight script for the AdminAuthorization package change the ownership of the payload to roo:wheel for good measure.

I found it quite interesting that when I went to build the packages, I had to supply user name and password as my administrator's account did not have sufficient privileges to archive the /usr and /usr/local folders. I had to authenticate to build the package, but an administrator doesn't have to authenticate to install the very same files. This does not seem right at all.

Matt

Mac Mini G4; B&W G3/300

biovizier

Level 5

7,925 points

Jul 28, 2006 6:53 PM in response to Matt Broughton

I heard back from Apple, and the bug report has been marked a "duplicate". A note sent in parallel to product-security@apple.com received the response that the issue is "known" and is "being addressed".

Good point about the script hazard - I accidentally discovered the same thing trying to do something else with the package. That really lowers the bar in terms of both what a user needs to know and what tools they need on hand to take advantage of the weakness...

Jul 28, 2006 7:00 PM in response to biovizier

Glad to hear that it had been previously reported and the Apple recognizes it as a problem.

Matt

Jul 29, 2006 10:36 AM in response to biovizier

Of course, nothing really changes - most people have
been advising against routinely using an "admin"
account anyway...

So it seems that I'm the only one here who uses the default (admin) account for daily work. 😉
I don't like the overhead of having another account. Ubuntu, for example, uses the same concept, the default account being a sudoer. This motivated me to do the same with OS X. I find this pretty nice for systems used by a single user only and I wish that Windows would do it the same way.
I think that if the concept was properly implemented, working with a sudoer account is almost as secure as using a second, restricted account.

We should not forget that we are talking about an error in the system. There were also errors in the past which could be used to gain root privileges from a restricted account. So there's always some risk left - the question is, how high the risk is.

Jul 29, 2006 11:25 AM in response to kullerhamPster

So it seems that I'm the only one here who uses the
default (admin) account for daily work. 😉

I still use an admin account for daily work. I just happen have my main account set up as user 502 rather than the default 501. This is mainly for my convenience. I provide support help for my sister's SOHO environment. For their computers, the first admin account set up the same on each computer. I use subsequent accounts the other stations. Nobody is running an administrator account in their setting. Partly for security reasons but also so they don't mess things up quite as easily even though they do have the admin password. So my using account 502 as my main account gives me more the look and feel of a multi-account setup.

We should not forget that we are talking about an
error in the system. There were also errors in the
past which could be used to gain root privileges from
a restricted account. So there's always some risk
left - the question is, how high the risk is.

In this case, I would prefer to say that there is a bug in the Installer program. I don't think it is a system wide fault. If you compile source code, you have to authenticate to install. If you want to make a directory in /usr, you have to authenticate. The PackageMaker used to create an installer requires the proper authentication to archive files for the package. Perhaps the PackageMaker application should be enhanced so that it takes into account the default location when it determines whether sudo authentication is needed to archive files when building a package. That might have brought the incorrect file ownership to the attention of the person making the PHP installer. It is only the Installer application that elevates the level of access improperly.

There have been system wide holes such as the when it was possible to mount a remote disk without our knowledge or consent. I don't believe that the Installer situation is system wide.

Matt

Mac Mini G4; B&W G3/300

Jul 29, 2006 1:49 PM in response to Matt Broughton

I still use an admin account for daily work. I just
happen have my main account set up as user 502 rather
than the default 501. This is mainly for my
convenience. I provide support help for my sister's
SOHO environment. For their computers, the first
admin account set up the same on each computer. I
use subsequent accounts the other stations. Nobody
is running an administrator account in their setting.
Partly for security reasons but also so they don't
mess things up quite as easily even though they do
have the admin password. So my using account 502 as
my main account gives me more the look and feel of a
multi-account setup.

I'm afraid I don't quite understand the advantage of setting the uid from 501 to 502 in your system configuration. So the 501 account also exists on each computer?

In this case, I would prefer to say that there is a
bug in the Installer program. I don't think it is a
system wide fault. If you compile source code, you
have to authenticate to install. If you want to make
a directory in /usr, you have to authenticate. The
PackageMaker used to create an installer requires the
proper authentication to archive files for the
package.

Yes, I agree, it seems that the error is only in the installer, and thus not as dramatic as if it would be a system-wide problem. Nevertheless, the installer is part of the system, and this is a possibility to run a script with elevated privileges without authentification.
As far as it seems up to now, the threat arising from this bug is not that big, as user interaction is required in any case.
By the way: I wonder what happens when running the Installer from a restricted account. Do the pre- and postflight scripts run with higher privileges, too?

There have been system wide holes such as the when it
was possible to mount a remote disk without our
knowledge or consent. I don't believe that the
Installer situation is system wide.

Yes. I remember an issue that was discussed about a year or so ago, where there was an error which allowed a local user to gain root privileges. Something like this is a lot worse.

Jul 29, 2006 4:31 PM in response to kullerhamPster

Umm have any of you bothered to run this by Marc (ie the owner and devloper of entropy.ch)? He might give you some more info yuore missing. Hes quite responsive and open to inquiry...

Jul 29, 2006 5:29 PM in response to kullerhamPster

I'm afraid I don't quite understand the advantage of
setting the uid from 501 to 502 in your system
configuration. So the 501 account also exists on each
computer?

I didn't change the uid at all. I still have the first account set up when you install the OS (uid 501). I have designated that account as the "master" admin account on all the computers for which I have control or provide support. Additional accounts are then created as needed with the appropriate privileges. I do not use the account with the uid of 501. The computers in the SOHO environment start their user accounts with 503 and are not admin accounts.

One big advantage to me is that I can create a master image for distribution once they have acquired the proper number of licenses. This allows me to include some extras such as the w3c.org's 'checklink' program which they utilize by running an AppleScript. The 'checklink' program requires the build and installation of additional perl modules. It is far easier to provide it as a built in rather than lead them keystroke by keystroke (literally) through the process of building and installing programs.

There are no real day to day operational advantages for the average single user machine in my account scheme.

By the way: I wonder what happens when running the Installer
from a restricted account. Do the pre- and postflight scripts
run with higher privileges, too?

The installer will ask for authentication where either admin or root authorization is required. Yes, after proper authentication, the scripts are run as root at the current time.

Matt

Mac Mini G4; B&W G3/300

liyanage

Level 1

0 points

Jul 30, 2006 2:35 AM in response to Anthony Cunningham

I don't know any more about this issue, someone just sent me a link to this very interesting discussion.

I was actually wondering why there is no password dialog myself while testing my PHP 5 package, but I never investigated it. From what I read here, it does look like an Installer.app security issue.

MacBook Pro Mac OS X (10.4.7)

Installer priviliges