Originally Posted by semthex

Because this topic is highly intresting, I opened a IRC channel for OSx Security on irc.osx86.hu with the name #osxsecurity in case anybody is intrested in working with that a bit.

Thanks, I will come in at some point.

You might be interested in working on some kernel security (and OS X) testing programs with me too.

These need not be open-source projects either, there is quite a bit of money to be made here from government concerned about operating system security.

We have a very talented group of people here and I have been thinking for some time that we should work together to start a real software company.

NSA OS X Security Configuration Guide notes (Chapter 4, continued):

- p. 46: Setting the Global umask
The umask setting determines the permissions of new files and folders created by a
user. The default umask setting, 022, removes group and world write permissions.
With a umask setting of 027, files and folders created by a user will not be readable
by every other user on the system but will still be readable by members of his
assigned group. The owner of the file or folder can still make it accessible to others
by changing the permissions in the Finder’s Get Info window or by using the chmod
command. The NSUmask setting for all users can be set to 027 (decimal equivalent
23) by issuing the following command in a Terminal window:

sudo defaults write
/Library/Preferences/.GlobalPreferences NSUmask 23

Note that the path above refers to the
domain .GlobalPreferences, not to the
file .GlobalPreferences.plist, which might
accidentally be filled in while using the
shell autocomplete feature.

This command will affect the permissions on files and folders created by programs
that respect the Mac OS X NSUmask settings. Programs should follow the value set
for NSUmask, but there is no guarantee that they will. Also, users can override their
own NSUmask setting at any time. The changes to the umask settings take effect at
next login.

This is kind of interesting, one easily increase general security on file and folder. This obviously is indicated for mult-user machines, I am wondering if there is any point to doing this on single user machines. It also looks like one could tighten this up even more, by switch from 027 to something (perhaps 700?) that disallows any other users access.

- pp. 46-47 Securing Initial System Accounts
Two accounts on the system require attention before adding and configuring user
accounts. First, the permissions on the home folder of the initial administrator
account should be changed. Second, any necessary modifications to the root account
should be performed.

Restricting Administrator’s Home Folder Permissions
When FileVault is not enabled, the permissions on the home folder of the
just-created administrator account allow any user to browse its contents. To change
the permissions on the administrator’s home folder, issue the following command in
a Terminal window, where <adminname> is the name of the account. The 700
permission setting allows only the administrator to read and browse files in his home
folder.

sudo chmod 700 /Users/<adminname>

Securing the Root Account
Like other UNIX-based systems, Mac OS X includes a root account that can perform
any action on the system. Administration on most UNIX-based systems is
performed through the root account and sometimes multiple administrators share
access to the root account, which can make it impossible to distinguish the actions of
one administrator from another in the audit logs. Mac OS X installs with the root
account disabled, preventing direct root login, and it is strongly recommended that
the root account remain disabled.

Some this information may be specific to Panther (10.3). I need to check and see if Tiger (10.4) does indeed allow all user accounts access to the initial administration account. The NSA goes on to describe how an enabled root account can be disabled (the default state) by NetInfo Manager.app. Even though root should not be enable it is interesting to take a look at the "user" accounts in NetInfo Manager anyways. The number of default OS X accounts seems to imply that setting a tight NSUmask as per above might be a wise move.

- p.49 Using sudo
...
The system uses a file called /etc/sudoers to determine which users have the
authority to use the sudo program. This file initially contains the root account and
all administrative accounts.

Interesting.

The NSA next goes into securing OpenFirmware (pp. 49-52) which is only applicable to PPC Macs. This is:

- p. 49 To prevent users from obtaining root access by
booting into single user mode or booting from alternate disks...

I have not looked at EFI with respect to this issue nor do I have an EFI Mac yet. However, I believe that OpenFirmware is different that EFI here (or least with respect to real Macs) in that Apple does not provide access to the EFI shell like it to the OpenFirmware command prompt. EFI is very well thought out, so I suspect there are some similiar security features that are availble, however I do not know if it in fact password protected either. Since EFI is modular, it is theoretically possible to add a password protection as well.

I know that one some BIOS machines, like my Intel BadAxes, there is some password functionality built-in. Interfacing this with OSx86 might be possible. Otherwise, it seems like it might be possible to somehow disable single-user boot mode on OSx86 for enhanced sercurity. In short, this big hole in OSx86 security and one good reason why FileVault should be used.

It may or may not be good idea to try to secure single-user boot mode on OSx86 this way:

- pp. 51-52 Only if the ability to boot into single-user mode is operationally required should a
password be provided for the root account in /etc/master.passwd. To provide
this password:

1. Log in as an administrator.
2. Start the Terminal application, located in /Applications/Utilities.
3. At the prompt, issue the command:
cd /etc
4. To edit the master password file, issue the command:
sudo pico master.passwd
5. Within the editor, delete the asterisk following the word “root”.
6. Open a new terminal window and issue the following command, replacing
<xx> with two random characters and <password> with an appropriate
8-character password:
openssl passwd -salt <xx> <password>
A hash of the password will be displayed after executing the command.

- p. 52: Logon Warning Banners
A logon banner can be used to provide notice of the system’s ownership, warn away
unauthorized users, and remind authorized users of their consent to monitoring.
...
Edit the file
/Library/Preferences/com.apple.loginwindow.plist
...
<key>LoginwindowText</key>
<string>THIS IS A DEPARTMENT OF DEFENSE COMPUTER
SYSTEM. USE OF THE SYSTEM IMPLIES CONSENT TO
MONITORING. ANY UNAUTHORIZED USE OF THE SYSTEM WILL
BE PROSECUTED.
</string>

Hmm... sounds like fun.

The remainder of the NSA's Chapter 4 has to wtih logging (apparently the default setup is fine for single users), removing kexts to disable hardware security threats (we seem to have the opposite problem in OSx86) and disabling OS 9 (aka Classic) which I do not think even exists on OSx86.

Chapter 5 is next and last in the NSA's OS X security guide. It is titled "Configuring User Accounts."

***CHAPTER 5, Configuring User Accounts***

- p. 61: Guidelines for Creating Accounts
Accounts should never be shared. Each user should have his own individual
account, and each system administrator should have his own administrative
account. Each administrator should also have a regular user account for normal
activities, and should use his administrative account only for administrative
activities.
...
• Requiring administrators to have a personal account for individual use and an
administrative account for administrative purposes reduces the risk of the
administrator inadvertently making system configuration changes while
performing normal non-administrative tasks.

So, this is the idea I previously mentioned about using a non-adminstrative account for normal use. I would just add that this would also seem to give some protection against a trojan executing in the name the active account (i.e. it would be limited to a regular user account as opposed to an administrator).

The NSA then goes on to describe how to create user accounts with security limits. Specifically, a user can be restricted to executing specified applications, accessing System Prefs., changing their password and burning disks. Of the applications to restrict access, the NSA notes: Console, DiskUtilty, NetInfo Manager, Network Utility, OBDC Adminstrator, Terminal, Installer, X11, Internect Connect, Director Access and fax software (in addition to application associated with wireless functionality).

- p. 68: Securing Users’ Accounts
This section describes user account settings that should be implemented before a
user is given access to the account.

Restrict Home Folder Permissions
When FileVault is not enabled, the permissions on the home folder of a newly
created user account allow any other user to browse its contents. These permissions
are needed to allow the Public and Public/Drop Box folders within each home
folder to operate properly. However, users may inadvertently save sensitive files
directly into their home folder, instead of into the more-protected Documents,
Library, or Desktop folders. Although it will break the intended function of the
Public and Public/Drop Box folders, the permissions on each each user’s home
folder should be changed to prevent other users from browsing its contents. To
change the permissions, issue the following command from a Terminal window:

sudo chmod 750 /Users/<username>

where <username> is the name of the account. This command should be executed
immediately after the creation of a new account. The 750 permission setting still
allows members of the group owning the folder to browse it, but on Mac OS X 10.3
that group consists only of the user. If more advanced group management is
performed, and members of the group owning the folder should not be granted
permission to browse it, then the command above should be issued with the
permission 700 instead of 750.

The user, as the owner of his home folder, can alter its permission settings at any
time.

So, I still need to see how Tiger (10.4) changed some of the defaults permissions, but the idea is very clear. One can tighten up the user accounts quite a bit, beyond FileVault. I also need to find out exactly how FileVault changes the permissions setting, it seems like 700 is implied by the NSA.

- p. 73: Overriding the Default umask
The default umask value can be overridden for a particular user, if needed. To do so,
log into the user account to be changed. For example, to set the default umask to
027 (decimal equivalent 23) so that other group members can read files created by a
user, issue the following command in a Terminal window:
defaults write –g NSUmask –int 23


So, not only can the global NSUmask be set, but also one local to users. The same caveats apparently apply.

- p. 74: Setting Up Keychains for a User Account
Mac OS X provides an application called Keychain Access that allows a user to
manage collections of passwords and certificates, each of which is called a
keychain. Each keychain can hold a collection of credentials and protect them with
a single password. Passwords, certificates, and any other private values (called
secure notes) that a user or application places into a keychain are encrypted.
These values are accessible only by unlocking the keychain using the keychain
password.
...
When a user must keep track of a multitude of passwords, he is likely to either make
the passwords identical for all the systems, or keep a written list of all passwords.
Use of keychains can greatly reduce the number of passwords a user must
remember. Since the user no longer has to remember passwords for a multitude of
accounts, the passwords chosen can be very complex and could even be randomly
generated.

One disadvantage of using a keychain, however, is that if the user does not choose a
strong password, or if the password is compromised, then all the accounts protected
by that keychain may be compromised. Another disadvantage is that any application
may make use of the Keychain API to query for passwords. Therefore, care must be
taken in determining which applications are granted access to a keychain.

Despite these disadvantages, keychains provide some additional protection for
passwords, passphrases, certificates, and other credentials stored on the system.
Also, in some cases, such as using a certificate to sign an e-mail message, the
certificate must be stored in a keychain. If a credential must be stored on the system,
it should be stored and managed using the Keychain Access utility. The decision to
use keychains should be determined by evaluating policy, operational needs, and
operational environment.

So, the use Keychains is somewhat implicit in the secure use of OS X. In fact, whether you know it or not you are probablly using Keychains in the background. This becomes more explict with encrypted email is used, which I plan to get into later. One OS X security issue that I am very concerned about is actual account security in sites like Hackint0sh.

I would like to use Keychain Access to manage my forum and online shopping passwords but I am not sure if the Safari (or other browsers like FireFox) support this. I will be looking into this. This could be another angle on security software, modifying Safari with a plug-in to add certain security features.

- p. 79: Keychain Examples
Keychain 1: Frequently accessed credentials (e.g. Mail)

The first keychain configured here is designed to protect credentials that are
accessed frequently and automatically whenever a user is logged in. A good example
of this would be an e-mail account password used by the Mail application. If the
keychain holding the credentials used by Mail is set to re-lock every 5 minutes, it is
likely that the user will have to re-authenticate the keychain every time the Mail
application tries to check for new mail. Most users will find this unacceptable. A
keychain protecting credentials for the user’s e-mail account should be automatically
unlocked when the user logs in, and should only re-lock when the user logs out or the
machine sleeps. Also, each item within the keychain should be configured to allow
unrestricted access only to the application for which that credential was intended. All
other applications should be required to re-authenticate for every access.
...
Keychain 2: Moderately accessed credentials (e.g. database access)

This keychain is designed to protect credentials that are accessed frequently and
automatically whenever a user is accessing a particular application that needs a
credential from a keychain. An example of this might be a database that requires
credentials for every query. In this situation, the desired behavior entails
authentication of the keychain password at the beginning of a session, and re-
authentication on a periodic basis (e.g. every 15 minutes) rather than for every query.
...
Keychain 3: Infrequently accessed credentials (e.g. web accounts)

This keychain is designed to protect credentials that are either accessed infrequently,
or that require very strict control and re-authentication for every access. Initially, it
might not seem to make sense to put credentials in a keychain if the user must enter
a password every time the credential is used. But if the user uses a single keychain
to store all such credentials (e.g. all web-based accounts) then he may use completely
different, randomly generated passwords for every account protected with that
keychain, and have a single, very strong password for that keychain that will access
all accounts. This would be better than using simple passwords for each account,
writing down the passwords for each account, or using a single password for several
accounts across different systems with different levels of password protection.

Again, it is not clear to me if Keychains are already interfaced with web-browsers or not. I have to assume that username and password tags are clear enough to be parsed out of HTML (or whatever), but I have to look at this issue in general.

The NSA has more to say about key-chains, including comments about making them portable by using USB devices and such.