Page 4 of 6 FirstFirst 123456 LastLast
Results 31 to 40 of 57
Discuss Xtreme OS X Security at the Using Leopard - Hackint0sh.org; Originally Posted by semthex Because this topic is highly intresting, I opened a IRC channel ...
  1. #31
    Professional Array bofors's Avatar

    Join Date
    May 2006
    Posts
    80
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    12

    Default

    Quote Originally Posted by semthex View Post
    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.


  2. #32
    Professional Array bofors's Avatar

    Join Date
    May 2006
    Posts
    80
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    12

    Default

    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.
    Last edited by bofors; 03-11-2007 at 04:24 PM.

  3. #33
    Professional Array bofors's Avatar

    Join Date
    May 2006
    Posts
    80
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    12

    Default

    - 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.

  4. #34
    Professional Array bofors's Avatar

    Join Date
    May 2006
    Posts
    80
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    12

    Default

    - 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.
    Last edited by bofors; 03-10-2007 at 06:18 PM.

  5. #35
    Professional Array bofors's Avatar

    Join Date
    May 2006
    Posts
    80
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    12

    Default

    - 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."
    Last edited by bofors; 03-10-2007 at 09:21 PM.


  6. #36
    Professional Array bofors's Avatar

    Join Date
    May 2006
    Posts
    80
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    12

    Default

    ***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).
    Last edited by bofors; 03-11-2007 at 05:09 PM.

  7. #37
    Professional Array bofors's Avatar

    Join Date
    May 2006
    Posts
    80
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    12

    Default

    - 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.

  8. #38
    Professional Array bofors's Avatar

    Join Date
    May 2006
    Posts
    80
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    12

    Default

    - 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.
    Last edited by bofors; 03-11-2007 at 06:04 PM.

  9. #39
    Professional Array bofors's Avatar

    Join Date
    May 2006
    Posts
    80
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    12

    Default

    - 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.
    Last edited by bofors; 03-11-2007 at 06:04 PM.

  10. #40
    Professional Array bofors's Avatar

    Join Date
    May 2006
    Posts
    80
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    12

    Default

    - 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.


 

 
Page 4 of 6 FirstFirst 123456 LastLast

Similar Threads

  1. MacNN: JBL ships OnBeat Xtreme iOS dock with Bluetooth
    By hackint0sh in forum Latest Headlines
    Replies: 0
    Last Post: 11-17-2011, 11:00 PM
  2. MacNN: Planon intros DocuPen Xtreme X-Series
    By hackint0sh in forum Latest Headlines
    Replies: 0
    Last Post: 11-04-2009, 11:10 PM
  3. MacNN: First Look: See2 Xtreme, USB video card
    By hackint0sh in forum Latest Headlines
    Replies: 0
    Last Post: 08-28-2008, 10:40 PM
  4. Xtreme OS X Security
    By bofors in forum Genuine Mac Support
    Replies: 3
    Last Post: 07-13-2008, 12:33 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Powered by vBulletin®
Copyright © 2014 vBulletin Solutions, Inc. All rights reserved.
Search Engine Friendly URLs by vBSEO
(c) 2006-2012 Hackint0sh.org
All times are GMT +2. The time now is 01:40 PM.
twitter, follow us!