Posts Tagged ‘ACL’

Adding incoming and outgoing access rules on a Cisco ASA

Saturday, March 17th, 2012

To understand incoming and outgoing rules there are a couple of things to know before you can define your rules. Let’s start with an understanding of traffic flow on an ASA. All incoming rules are meant to define traffic that come inbound to the ASA’s interface. Outgoing is for all traffic that is going outbound of an ASA’s interface. It does not matter which interface it is since this is a matter data flow and each active interface on an ASA will have it’s own unique address.

To try an explain this further let’s say we have and internal interface with an IP address of that is for your local area network to connect to. You can add a permit or deny rule to this interface specifying whether incoming or outgoing  traffic will be permitted or not. This allows you to control what computers can communicate past that interface or not. Essentially you would define most of your rules for the local area network on the internal interface, governing which systems/devices could access the internet, certain protocols, or not.

Now if you know about the basic configuration of an ASA you know that you have to set the security level of the Internal and External ports. So by default these devices allow traffic from a higher security interface to a lower security interface. NAT/PAT will need to be configured depending on if you want to define port traffic for specified protocols.

For this article I will just mention that their are several types of Access Control Lists (ACL) that you can create on an ASA. These types are Standard, Extended, Ethertype, webtype, and IPV6. For this example we will use Extended because most likely that is what most everyone will use the most. With extended ACL not only can you specify IP addresses in the access control list, but you can specify port traffic to match the protocol that might be required.

Lets look at the the examples below:

You will see we are in the configuration terminal mode

ASA(config)# access-list acl extended permit tcp any host eq 80

-So the first part “access-list acl” means the access list will be named “acl”.
-Next you have a choice between type of access list. We are using Extended for this example.
-The next portion is the permit or deny option and we have permit selected for this statement.
-On the next selection that say’s “any” this refers to inside traffic (simply meaning that any internal traffic is allowed). If you dont use any you can specify specific devices by using “host and the IP address like that last part of this ACL statement.
-The next part of this refers to specifying a specific host address of equals port 80.

So this example tells us that our access control list named ACL will allow any inside traffic out the host address of that is internet traffic.

Later you will notice that your statement will look like this on the ASA

ASA(config)access-list acl extended permit tcp any host www
Notice how “eq 80″ default http traffic changed automatically to www) This is common on Cisco ASA devices).

ACLs and NFS

Thursday, January 14th, 2010

The permissions that a user obtains for NFS shares will boil down to effective permissions. NFS doesn’t support ACLs, but it does honor them for Mac OS X NFS clients when bound to the directory.: if a user is granted read/write via an ACL, they WILL have read/write access via NFS. However, there are a few things to note here.

First and foremost, granular ACL’s won’t translate completely. Secondly, although you might have effective write privileges via ACL’s, if you don’t have write privileges via POSIX, it will *look* like you don’t have privileges when you do an `ls` on the mounted NFS volume, however, if you try to read or write a file, it will work without issue. Poorly written software might inspect the POSIX permissions and determine that you don’t have access when you really do. Most software will attempt to read/write an asset and will report errors when encountered (as it should).  Lastly, ACL inheritance IS honored over NFS as well, so any files/dirs your users will create will have the appropriate ACL’s assigned on the backend, though displayed POSIX permissions once again won’t be especially accurate.

The Time Machine Safety Net

Monday, February 2nd, 2009
Time Machine utilizes Leopard’s new MAC framework, providing a “safety net” to ensure the integrity of your backups. Access control provisions are applied via a kernel extension located at /System/Library/Extensions/TMSafetyNet.kext, which makes calls to _mac_policy_register and _mac_policy_unregister. All of this results in a backup set which contains data which is immutable via standard means. For instance, attempting to delete a Time Machine backup via the cli utility ‘rm’ will result in failure, as well as any other cli file operation utility which attempts to alter Time Machine backups. 
It seems that the system enforces the restrictions based upon all of the
following conditions being met:
  1. Has ACE ‘group:everyone deny full control’
  2. Resides in a directory “Backups.backupdb” located at volume root with the same deny ACE

Steps to create the safety net:

$mkdir -p /Backups.backupdb/test/test1
$chmod -R +a# 0 "group:everyone deny add_file,delete,add_subdirectory,
delete_child,writeattr,writeextattr,chown" /Backups.backupdb/
$rm -rf /Backups.backupdb/test
rm: /Backups.backupdb/test/test1: Operation not permitted
rm: /Backups.backupdb/test: Operation not permitted

Attempts to alter this data is then unsuccessful. However, there are a few back doors here. There exists a cli binary at /System/Library/Extensions/TMSafetyNet.kext/Contents/MacOS/bypass
which allows you to supply a command + args as an argument and completely bypass the access restrictions. Likewise, GUI level apps can delete these items by escalating via the authorization trampoline.

A brief introduction to Mac OS X Sandbox Technology

Thursday, April 17th, 2008

Note: For more information about the information contained in this article, contact us for a professional consultation.

In all versions of OS X previous to Leopard, access control restrictions were limited to a security model referred to as Discretionary Access Controls (DAC). The most visible form of DAC in OS X is in it’s implementation of the POSIX file-system security model, which establishes identity-based restrictions on an object in the form of a subject’s user or group membership. Similarly Access Control Lists are a form of discretionary control, though they are far more extensible and discrete then the POSIX model. In such models,  newly created objects or processes inherit their access rights based upon those of the creating subject, so that any spawned objects are not granted access rights beyond that of their creating subject. The key idea behind the DAC model is that the security of an object is left to the discretion of the object’s owner; an object’s owner has the ability to assign varying levels of access control to that object within the confines of the DAC implementation. The DAC model has for decades been a staple in the management of both object/process creation and access across all mainstream computer systems due to it’s user-centric nature. However there is a persistent caveat in these implementations;  in all mainstream implementations of such models, there exists a superuser which has the capabilities to completely bypass access restrictions placed on objects. In POSIX-based Operating Systems such as Unix, Linux, or OS X, this superuser exists in the form of the root user. The existence of such a loophole presents a bit of a paradox. On one hand, it introduces several obvious security ramifications by providing capabilities to completely bypass the DAC model all together; any processes which are invoked by the superuser inherit the “god mode” access controls, they have free reign over the entire system. At the same time, the existence of the superuser account becomes a vital tool for the practical administration of data objects and system resources. In a perfect world, this wouldn’t necessarily be a bad thing. Unfortunately that’s not the world we live in, and it is not uncommon to hear about processes being hijacked for ill-will. If the compromised process has been invoked by the superuser, then the entire system has been compromised, including all user data with it.

With 10.5 Leopard, Apple has introduced a new low-level access control model into their OS, based upon the mandatory access control (MAC) model. Conceptually, the MAC system implements restrictions based upon actors, objects, and actions. In such a system, the actor typically assumes the form of a process, thread, or socket. The object can be any type of resource, such as a file, directory, socket, or even a TCP/UDP network port, among others. The action is simply the request of the actor to be applied to the respective object, and varies depending on the type of object involved in the request. Referring back to the file system model; the actor would be a word processor, the object would be a .txt flat file, and the action would be a call to either read to or write to that text file. When the actor requests access to the object, the MAC authorization system evaluates security policies and decides whether the request can proceed, or if it should be prohibited. In a pure MAC model, the object or process ownership is not generally a consideration; individual users do not have the ability to override defined policy.

Leopard enforces the MAC model via a new framework, architected from TrustedBSD’s MAC framework. This framework introduces “sandbox” access control capabilities which allow a developer or user to apply access control policies to a process, restricting privileges to various specified system resources. The restrictions are generally enforced upon acquisition, so any active file descriptors would not be immediately affected by any policy changes, however, any new open() operations would be subject to the new restrictions. In a fashion similar to the DAC model, new processes and forks will inherit the access restrictions of their parent. In Leopard, these restriction policies can be pre-compiled into any given program, or they can be applied to any executable at runtime.

While Leopard’s MAC framework is based off of TrustedBSD’s,  it’s implementation deploys only a subset of control points provided by the TrustedBSD implementation. Noticeably absent are the majority of the Security Policy Modules available for TrustedBSD and FreeBSD implementations, such as Biba, MLS, or NSA’s FLASK/TE (implemented in SEDarwin), though perhaps some day we’ll see some of these ported to Leopard’s MAC framework.  For now, Apple has offered their own Security Policy Module dubbed “Seatbelt”, which is implemented as a KEXT installed at /System/Library/Extensions/seatbelt.kext.  As of 10.5.2, the feature set of Seatbelt seems to be very much in flux. The only documented way to apply these controls in code is via the sandbox_init() function. Utilizing this function in code provides a way for an application programmer to voluntarily restrict access privileges in a running program. sandbox_init() is very limited at this point, providing only 5 pre-defined constants:

• kSBXProfileNoInternet  – disables TCP/IP networking.

• kSBXProfileNoNetwork – disables all sockets-based networking

• kSBXProfileNoWrite – disables write access to all filesystem objects

• kSBXProfileNoWriteExceptTemporary – disables write access to filesystem objects except /var/tmp and `getconf DARWIN_USER_TEMP_DIR`

• kSBXProfilePureComputation – all OS services are restricted

An application can utilize one of these constants to restrict capabilities in spawned processes or threads, minimizing the potential damage that can occur in the event that the process is compromised. Figure 1 shows an example implementation of the kSBXProfileNoWrite profile in code:

Figure 1.





int main()


int sb, fh;

char **errbuf;

char rtxt[255];

char wtxt[255] = "Sandboxed you aren't\n\n";

// init our sandbox, if we don't return 0 then there's a problem

sb = sandbox_init(kSBXProfileNoWrite, SANDBOX_NAMED, errbuf);

if ( sb != 0 ) {

        printf("Sandbox failed\n");

return sb;


fh = open("test.txt", O_RDONLY);

if ( fh == -1 ) {

perror("Read failed");

} else {

read(fh, rtxt, 255);


printf("FileContents:\n %s\n", rtxt); 


fh = open("test.txt", O_RDWR | O_CREAT, 0000644);

if ( fh == -1 ) {

perror("Write Failed"); } else {

write(fh, wtxt, strlen(wtxt));


printf("Successfully wrote file!\n");


return 0;


Compiling and running this code returns the following results:

% ./sandBoxTest

FileContents:  hello

Write Failed: Operation not permitted

So, even though our POSIX permissions allows for read/write access to the file, the sandbox prevents it, regardless of user. Running the program even with root privileges yields the same results.

Currently, the options provided by Apple are very all-or-nothing, particularly in the area of file system restrictions. In this way, Seatbelt acts more as a clumsy broadsword, lopping off functionality in large chunks at a time for the sake of security. In this form, Seatbelt has minimized use outside of very vertical applications or the increasingly rare applications that don’t utilize network communication in one way or another. Though these limitations will significantly limit widespread adoption, I believe it would be a mistake for a developer to shrug off Seatbelt as a whole.

Luckily, Seatbelt has an alternate application, though currently it is not officially supported. As I mentioned earlier, it is possible to apply sandbox restrictions to any pre-complied executable at runtime. This is done via the sandbox-exec binary, and uses predefined profiles housed at /usr/share/sandbox which provide for fine-grained control of resources. These profiles use a combination of allow/deny rules in combination with regular expressions to specify system resource access. There are numerous control points, such as network sockets, signals, sysctl variables, forking abilities, and process execution, most of which can be tuned with fairly decent precision by utilizing a combination of regex and static inclusion sets. Filesystem objects and processes are identified via POSIX paths; there currently is no target validation performed ether via checksums or digital signing.

Figure 2 shows a sample sandbox profile that can be applied to restrict an application from making outbound communications and restricts file system writes to temporary directories and the user’s preferences folder. The ‘debug deny’ line tells seatbelt to log all policy violations. This proves to be very useful in determining filesystem and network activity by an untrusted program. It facilitates a quick-and-easy way to do basic forensic testing on any program acquired from an untrusted source. Figure 3 shows example log violations of a network-outbound violation, and of a file-write violation, respectively.

To apply a sandbox profile to a standard application bundle you must pass sandbox-exec the path of the mach-o binary file which is typically located in ‘Contents/MacOS/’, relative to the application’s bundle. You can specify a sandbox profile by name using the -n flag if the profile resides in /usr/share/sandbox, or you can specify a full path to a profile with the -f argument. Carbon applications may require the LaunchCFMApp wrapper to properly execute. See figure 4 for example syntax for both Cocoa and Carbon Applications.

Figure 2. Example sandbox profile

(version 1)

(debug deny)

(allow default)

(allow process*)

(deny network-outbound)

(allow file-read-data file-read-metadata

  (regex "^/.*"))

(deny file-write*      

  (regex "^/.*"))

(allow file-write*      

  (regex "^/Users/johndoe/Library/Preferences.*"))

(allow file-write* file-read-data file-read-metadata

  (regex "^(/private)?/tmp/"))

(import "")

Figure 3. Example log entries from TCP and filesystem write violations

3/4/08 12:15:10 AM kernel dig 79302 NET_OUTBOUND DENY l= unavailable r= UDP 1 (seatbelt) 

3/4/08 12:43:05 AM kernel sh 79147 FS_WRITE_DATA SBF /Users/Shared/test.txt 13 (seatbelt) 

Figure 4. Using launchd to sandbox cocoa and carbon applications.

Cocoa % sandbox-exec -n localonly /Applications/

Carbon % sandbox-exec -n localonly /System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp /Applications/Microsoft\ Office\ 2004/Microsoft\ Word

Unfortunately, the system seems to be far from finalized, and even some example profiles provided by Apple do not seem to be completely functional, or contain unimplemented control points. One example of this is seen when trying to implement IP-based network restrictions. Apple provides example entries for layer3 filtering in the included profiles, but they are commented-out and illicit a syntax error when ran. Additionally, Apple has a rather ominous warning in each of it’s provided profiles, stating that current profiles are deemed to be Apple System Private Interfaces, and may change at any time.

However, that’s no reason to completely ignore the technology. Given what has currently been implemented, and taking into consideration control points which are alluded to by Apple’s own imbedded comments, Seatbelt is showing significant promise to provide very fine-grained resource access capabilities. By utilizing these restrictions, applications and users can ensure that even in a worst-case scenario, possibilities for errant/hijacked process damage becomes mitigated and compartmentalized. There are many real-world situations where this type of access control model fits very well, particularly in complement to standard DAC systems: they can be used to mitigate privilege escalation opportunities for shell users, to confine behavior conformance of processes to defined resources (and there by protect against hacked processes), or as a forensic tool to determine software malfeasance. By providing these type of capabilities through the Seatbelt policy module, and by providing a path towards implementing more complex MAC policy modules, Leopard’s new MAC framework ushers in a new level of security and access control capabilities for OS X.

Leopard Server: Sharing Folders using Server Admin

Friday, November 2nd, 2007

We’ve gotten a few questions from people asking how you’re supposed to setup share points for Leopard Server. It’s relatively simple but will require a little getting used to for those who are used to configuring sharing options in Workgroup Manager.

To view the shared folders on a system, open Server Admin and click on the name of the server in the SERVERS list. From here, click on the File Sharing button in the Server Admin toolbar and you will see a list of the logical volumes that your server can see along with a handy Disk Space image showing how full the various volumes are. At this point you can click on Share Points to see which folders are currently being shared over SMB, AFP, NFS or FTP. If you click on Volumes and then the Browse button then you will be able to configure new folders to become share points that you want others to get access to. Browse to the folder to be shared and then click on the share button in the upper Right hand corner below the tool bar.

Now you are looking at 3 tabs along the bottom of the screen: Share Point, Permissions and Quotas. From here, click on Share Point and review the options: Enable AutoMount – provides options to setup an OD link to the volume Enable Spotlight Searching – allow the volume to be searchable using Spotlight Enable as TimeMachine Backup Destination – client computers can backup using Time Machine Protocol Options – brings up the screen that allows SMB, AFP, NFS and FTP settings to be configured (looks very similar to the old screen in Workgroup Manager)

Once you have configured the options for your share point click over to the Permissions tab. Now you can configure who has access to shared data. From here, the main change is that the Users and Groups window is a floating window, with a new look and feel, but with the same overall feature set. The next major change is that ACLs are listed above POSIX permissions, and when you drag a user or group into the window you will see a blue line indicating that you can drop the object off into the screen and it will stay.

Finally, click on the Quotas tab and notice that when you enable quotas you cannot drag users and groups into this window. Only users with a home folder on the volume can be configured for quotas using Server Admin. If you would like to configure quotas otherwise you can do so at the command line.

Leopard Server: Using Directory to Update LDAP Entries

Saturday, October 27th, 2007

If you’re migrating to Leopard and Leopard Server then you’ve likely noticed the welcome addition of a new program in /Applications/Utilities called Directory. Directory allows users bound into an Open Directory environment to update LDAP records provided they have access to do so. Using LDAP ACLs it’s possible to give users access to update their own directory information using an LDAP directory browser such as Directory.

When you open Directory you should see a listing of all of the directory information that has been created. From here you can create Shared Contacts, Groups, Locations and Resources. Each of these can be connected to a calendar. Groups can have multiple members and get a Mailing List, Calendar or Blog connected to them.

Resource types include Automobiles, Conference Phones, Copiers, Digital Cameras, Notebooks, Printers, Projection Screens, Projectors, Scanners and Video Cameras. Resources can be reserved in an iCal Server Calendar and can have a delegate. Delegates are users that are able to manage particular resources.

The fact that there are a lot of objects in the LDAP database that can be managed means that it’s important to have a tool for configuring who can manage them. Workgroup Manager has basic permissioning built it but it isn’t as granular as a lot of organizations will need. To get more granular it might be required to dip into the command line and configure LDAP using the configuration files. To get started with this, see the article from a couple of days ago about LDAP ACLs.

Leopard Server: Using ACLs with Open Directory

Friday, October 26th, 2007

In Leopard, Workgroup Manager supports rudimentary ACLs for the LDAP database. We’re all familiar with Access Control Lists by now. Especially in the Mac OS X Server community. However, we might not all be familiar with ACLs as they’re implemented in LDAP. But we should be, because LDAP is being used more and more as an address book, and with the new Directory application being shipped in Leopard it is conceivable that environments aren’t just going to use ACLs to secure LDAP but they’re also going to use them to allow users to self update their information in the directory. So in the interest of security and making the most out of the technologies build into LDAP, let’s cover LDAP ACLs for a bit. So to push beyond what you can do in Workgroup Manager, let’s take a look at building out more finely grained ACLs manually.

First, like with most things in LDAP ACLs are configured using the /etc/openldap/slapd.conf file. Below is the pertinent portion of this file that we will be looking at:

# Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap:// # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! Now, if we remove the commented out portions of the file or add more lines we can start to limit who has access to read and/or change what information in the LDAP database. Keep in mind that you always want to back up your slapd.conf file prior to doing so.

You can control access to each element in the database. Each ACL has an “access to” which is the elements in the LDAP database that you are granting or denying access for and then a “by” portion that lists who can do what to that portion of the database. An entire ACL can be listed on one line, as is done with policies that have only one user or group associated to them. For example, the following line gives anyone and everyone read access to the database: access to dn.base=”" by * read

For ease of use and reviewing, we typically put the “access to” on one line and the subsequent users or groups with access in their own “by” lines for more complicated ACL rule sets. Slapd parses the file in such a way that it realizes that “access to” means the beginning of a new ACL. The following is an example of some more complicated ACLs: access to attrs=userPassword by dn="cn=users,dc=318,dc=com" write by self write by * compare access to * by dn="cn=computers,dc=318,dc=com" write by users read by * auth Access levels in ACLs are hierarchical. Levels that are used are none, auth, compare, search, read and write. None is the lowest level of access and write is the highest. Each level includes the rights of all lower levels. In the above example, a user is able to write to their own userPassword record. This means that the user is also able to auth, compare, search and read that record.

ACLs are prosessed from top to bottom. This makes it important to put specific ACLs and by statements above more general ones. ACLs that restrict access to the userPassword attribute, followed by one applicable to *, that is, the entire LDAP database. In the above example, placing the userPassword ACL first causes the rule that allows users to change their own passwords to process before the wildcard that specifies everyone. When a * is used as a wildcard in the access to line of slapd.conf it means the entire database or tree of the LDAP database. When the * is used in the by line it typically denotes all users.

Access levels in ACLs are hierarchical. Levels that are used are none, auth, compare, search, read and write. None is the lowest level of access and write is the highest. Each level includes the rights of all lower levels. These two points, the first match wins rule and the inclusive nature of access levels, are crucial to understanding how ACLs are parsed. They also are important for making sure your ACLs don’t lead to either greater or lesser levels of access than you intend in a given situation.

It can be time consuming to go through every possible attribute by group and determine who has access to what. However, if you want to have users updating their own addresses, phone numbers, and other information, as can be done with the Directory application, this is often one way to accomplish this goal. You could also provide help desk users the ability to update the database using the Directory application but not allow them to access other records in the LDAP database, such as group memberships. Having a very granular ACL environment for records can also allow you to obtain a maximum level of security.

This can also be put into the schema in order to force replication between hosts. Keep an eye out for that article at a later date. ;)

For what it’s worth, at 318 we’ve found that commenting out each ACL helps us to keep track of who did what, why and what they were thinking when they did it. Happy OD everyone!!!