Tackling residual folder ownership when demoting user accounts in OS X
While demoting your user account to a non-admin account provides a more secure environment in OS X, it is likely that some system resources may still be accessible by the account. Here is how to locate and change those resources.
Recently as part of the ongoing coverage of the MacDefender malware developments we suggested that users consider running their systems under non-administrative accounts. This practice limits access privileges to the resources that a standard user can access without providing administrative credentials. This mainly consists of the user's home directory, unlike Admin accounts, which can access system directories and the applications folder. Running in a standard account therefore helps prevent the user and hence any programs running under the user's account (including malware) from making changes to system folders without first being prompted for confirmation.
In OS X you can downgrade your account either by creating a new account and migrating to it, or by creating a new admin account and then demoting your current one to a standard account. This second option is the method we have recommended most often because it best preserves your settings and data organization. However, while convenient it does have some potential to leave accessible resources in various system directories. Recently MacFixIt reader "Fred" wrote in discussing the potential for a previous admin account to leave behind folders (including application packages) within system directories that would still be accessible by the user account, even though that account is no longer an administrator.
For example, if you create a folder called "Tools" in your Applications directory and demote your account to a standard user account, then even though you now cannot create another folder like the Tools directory within the Applications folder, you can still write new items to the existing Tools directory since it is still owned by you. Additionally, if you install an application by dragging it to and dropping it in your Applications folder, then like the Tools folder the application will be owned by the current user account, even if that account is demoted.
The question here is, does this pose a bigger security risk than if you were to create a fresh account and migrate your data and settings to that account? And the answer is no, while it does technically allow for more than the user's home directory to be accessed by the demoted standard user account, for most intents and purposes it is not a bigger security risk, especially on systems with only one user.
To start with, no known malware readily searches out writable directories and stores itself there; and, assuming this is a possibility, the malware would have to be coded to specifically locate those directories. Additionally, while the user account may have a few more directories to which it can write, any malware running would still be limited when accessing system files and directories (provided their permissions were left at default settings, which can be checked by running a Permissions Fix routine with Disk Utility). The only potential problem lies in a multiple-account system, because in some instances it would be possible for malware applications to be placed in locations where other users could access them. For instance, if a malware program is placed in a shared location such as the Applications folder (or a Tools directory within the Applications folder), then that malware could be run from this location by multiple different accounts on the system.
Keep in mind that these are just possibilities and speculation, and in reality there is not much additional security risk in keeping these accessible folders open on the system; however, some people may still wish to locate any files or folders within system directories that are owned by a particular account, and change them. While you can use the Finder's Inspector or Info windows to get information on multiple items, this can be a bit cumbersome. Alternatively, you can create a list of the items of which the owner is a particular user name by running the following commands in the Terminal from an admin account:
sudo find /Applications -user USERNAME>~/Applications.txt
sudo find /System -user USERNAME>~/System.txt
sudo find /Library -user USERNAME>~/Library.txt
In these three commands, change "USERNAME" to be the short name of the user account in question. When done, the commands will create text files (Applications.txt, System.txt, and Library.txt) in your home directory that contain lists of all the files, folders, and subfolders that are owned by the specified username. While the file listings might be extensive because they show all files and folders (including subdirectories), you should be able to locate common parent directories in the list that you can target and change the ownership of. To do this, you can delete the folder and its contents if not in use, or you can use the Finder's Info window to change ownership or use the Terminal command "chown" in the following manner:
Type "sudo chown -R USERNAME" in the Terminal followed by a single space. In this command, "USERNAME" is the name of the new owner, which should be "root" by default for most items in these directories, and the "-R" flag will ensure all enclosed files and folders in the directory get altered as well.
Drag the target file or folder to the Terminal window.
Press Enter, supplying your admin password to the command when prompted.
Ultimately this process is useful for adjusting the ownership of user-created folders that may be residing in various nonstandard locations such as the System folder, Applications folder, or global Library folder. Overall, to keep the system safe from odd permissions and ownership setups, the best thing to do is to run a Permissions Fix routine on the boot drive using Disk Utility, which will ensure that essential system resources are only accessible by the appropriate system and user accounts, regardless of what additional files and folders may have been put in these locations.
Questions? Comments? Have a fix? Post them below or e-mail us!
Be sure to check us out on Twitter and the CNET Mac forums.