Access Control in Tiger

Posted:
in Mac Software edited January 2014
After reading the 'brief' description of access control lists at the Apple website. I started digging around to see what they were talking about with respect to BSD 5.x. I found this link which explains mandatory access control (MAC) that is implemented in BSD 5.x. It would be sweet if this was ported over to Tiger instead a half baked attempt at ACL like you have in NT/XP.



http://www.freebsd.org/doc/en_US.ISO...dbook/mac.html



If you want to know *why* ACL in Windows is a pain, you can read the write up from Cygwin's documentation on NT security.

Comments

  • Reply 1 of 1
    talksense101talksense101 Posts: 1,738member
    Quote:

    ...consider how the MAC framework augments the security of the system as a whole. The various policies provided by the MAC framework could be used to protect the network and file systems, block users from accessing certain ports and sockets, and more. Perhaps the best use of the policies is to blend them together for a multi-layered security environment. The only downside is administrative overhead in cases of multiple file system labels, setting network access control user by user, etc.



    These downsides are minimal when compared to the lasting effect of the framework. A good implementation would hand total control over to the system administrator, who then could control various aspects of these policies using the sysctl utility.



    Thus a system utilizing MAC features should at least guarantee that a user will not be permitted to change security attributes at will; all user utilities, programs and scripts must work within the constraints of the access rules provided by the selected policies; and that total control of the MAC access rules are in the hands of the system administrator.



    It is the sole duty of the system administrator to carefully select the correct policies. Some environments may need to limit access control over the network; in these cases, the mac_portacl(4), mac_ifoff(4) and even mac_biba(4) might be a good starting point. In other cases, the need to secret items on the file system might be required. Policies such as mac_bsdextended(4) and mac_mls(4) exist for this purpose.



    Policy decisions could be made based on network configuration. Perhaps only certain users should be permitted access to facilities provided by ssh(1) to access the network or the Internet. The mac_portacl(4) would be the policy of choice for these situations. But what should be done in the case of file systems? Should all access to certain directories be severed from other groups or specific users? Or should we limit user or utility access to specific files by setting certain objects as classified?



    In the file system case, access to objects might be considered confidential to some users but not to others. For an example, a large development team might be broken off into smaller groups of individuals. Developers in project A might not be permitted to access objects written by developers in project B. Yet they might need to access objects created by developers in project C; that is quite a situation indeed. Using the different policies provided by the MAC framework; users could be divided into these groups and then given access to the appropriate areas without the fear of information leakage.



    Thus, each policy has a unique way of dealing with information flow. Policy selection should be completely based on a well thought out security policy. In many cases, the overall policy may need to be revised and reimplemented across the network. Understanding the different policies offered by the MAC framework will help administrators to choose the best policies for their situations.



    Also, understanding the implications involved with implementing the MAC framework into a specific environment; the following configuration must be completed before trying any of the examples or applying the information in the rest of this chapter to any environment.



Sign In or Register to comment.