Posts Tagged ‘Mac’

Mavericks Is Here, And It’s Free!

Tuesday, October 22nd, 2013

At 318 we’ve been hard at work preparing for the release of OS X 10.9, Mavericks and OS X Server 3.0. We’ve spent a lot of time writing, testing and filing our findings away. And now the time is here. Mavericks is available on the App Store, with OS X Server and iOS 7.0.3. Additionally, JAMF has released Casper 9.2 and other vendors are releasing patches as quickly as they can.

With new updates to Safari, the addition of iBooks, the new Maps app, better integration of the Calendar, Finder tagging, a new multiple display manager, newer automation features for FileVault, iCloud Keychain, new Notifications and Finder tags, Mavericks is sure to inspire a lot of people to upgrade immediately. Especially now that Apple has announced it’s free! Before you have hundreds of people upgrade in your environment though, check out the new Caching Server 2 in Mavericks Server app. It’s awesome and will help make sure you can still stream some Howard Stern while everyone is doing the upgrade.

OS X Server also gets a bunch of new updates, with Profile Manager 3 adding more that you can control/deploy, Xcode server providing code sharing, new command line options, new options within existing services, etc. Definitely check it out!

And if you need any help with this stuff, we’re more than happy to help prepare for and implement upgrades, whether it’s just for a few clients or for a few thousand!

Remote Desktop 2

Monday, October 21st, 2013
Up until the last few days, Microsoft’s Remote Desktop Connection client for OS X was getting a bit long in the tooth. But, just in case you missed it because of the Windows 8.1 update, Microsoft also released a new version of Remote Desktop Connection for Mac and its first versions for Android and iOS. Software is available only in each device’s app store:

Enroll Existing 10.8 Machines In Profile Manager (or another MDM) Using Apple Remote Desktop

Thursday, October 17th, 2013

Since we can now do less and less with MCX, we need to rely on Profile Manager for user and machine-specific management inside of OD. This is very easy if you are re-imaging all of your machines (using automated enrollment with Deploy Studio), but what about environments that have upgraded to 10.8 organically? Or if you’re attempting to manage machines that are already in use? If you’ve got ARD or SSH access, you’re in luck, as you can very easily push an Enrollment Profile that will automatically enroll the machine at the next reboot. This is done by manipulating files in /private/var/db/ConfigurationProfiles/Setup/. You can build a set of tasks in ARD to perform the following tasks.

First, we want to rm /private/var/db/ConfigurationProfiles/Setup/.profileSetupDone. At startup, OS X looks for this file and if not found, it will load any profiles found in the containing Setup folder. Make sure this command is run as root.

ARD1

Secondly, we need to actually copy the Enrollment Profile (and Trust Profile if needed) into /private/var/db/ConfigurationProfiles/Setup/. The profiles are loaded in alphabetical order, so make sure the names of the files will ensure that the Trust Profile runs first, or the Enrollment Profile will fail if you have not properly signed your configuration profiles. A good test to see if you need to send the Trust Profile as well is to install the Enrollment Profile you downloaded manually on a fresh test system – if it installs without error, you’re OK to use just that. If you get an error about needing a Trust Profile, either adjust your settings in Server.app to properly sign the Enrollment Profile in server, or install the Trust Profile on the machines as well.

ARD2

Note: You don’t have to install two profiles using most 3rd party MDM solutions, such as Casper, FileWave, etc.

It is important that we get the correct Enrollment Profile to load onto our target machines – you can’t simply log into yourserver.com/mydevices and use the profile that results from the “Enroll” link – this is a per-device file.  We need to get our Enrollment Profile from the admin page (yourserver.com/profilemanager). Once logged in, click the “+” in the bottom left corner and select “Enrollment Profile”.

Image1

Configure the profile as shown below and then download.

Image2

You can also download the Trust Profile from the same screen if needed.

Image3

Once you’ve deleted the .profileSetupDone file and loaded the appropriate profiles, the machines will self-enroll at next reboot (or if you’re a heartless admin, you can force a reboot via ARD). You can now enjoy device management via Profile Manager!

BCC Mail In OS X Server

Thursday, April 4th, 2013

OS X Server has the ability to bcc mail that flows through it. This can be a good way to keep a copy of mail for the purposes of things like legal requirements. To enable this feature, once upon a time you could use the GUI in OS X Server. These days, the feature is still there but is now accessed through the command line as the always_bcc_enabled option within serveradmin’s mail settings. To enable this option, use the following command:

sudo serveradmin settings mail:postfix:always_bcc_enabled = yes

Once enabled, you will also need to supply an actual address to bcc mail to, which is done using always_bcc as follows:

sudo serveradmin settings mail:postfix:always_bcc = "backup@318.com

Next, you’ll want to

sudo serveradmin stop mail
sudo serveradmin start mail

Finally, if there are any issues, putting the postfix logging facility into debug mode can help you triangulate, done using the following command (and restarting the mail service again):

sudo serveradmin settings mail:postfix:log_level = "debug"

Spin passwords using Apple Remote Desktop

Monday, February 18th, 2013

We routinely need to change our administrative passwords on multiple computers as part of our security policy. Since we already have remote access to many of our Mac OS X computers through Apple Remote Desktop (ARD), changing that administrator password is quick and simple.

First, a short shell script:

#!/bin/bash
# Change an account's password

ACCOUNT="ladmin"
PASSWORD="MyNewP@55w0rd"
/usr/bin/dscl . passwd /Users/$ACCOUNT $PASSWORD

if [ $? = 0 ] ; then
echo "Password reset."
else
echo "Password not reset."
fi

In ARD, click the Send UNIX Command button and paste the script into the top field. Choose to run this command as a specific user and specify root.

Send UNIX Command

From the Template drop down menu in the upper right corner select Save as Template… and save these settings with a descriptive name such as Spin ladmin password.

Save as template

To use and reuse this template, select the workstations with the old account password and click the Send UNIX Command button in ARD’s toolbar. Choose the Spin ladmin password template from the Template drop down menu. Adjust the account name and password accordingly in the script and then click the Send button.

ARD can spin dozens or hundreds of account passwords in just a few seconds without having to know the original.

Introducing Splunk: Funny name, serious logging

Thursday, November 15th, 2012

So, my boss says:

“Write an article called ‘Getting Started with Splunk.’”

I reply:

“What, you think I know all this stuff? This really would be a getting started article.”

But here it is and WOW is Splunk cool!

My only experience with Splunk up to a couple days ago was seeing a T-shirt with “Log is my copilot”. I knew it had something to do with gathering log files and making them easier to read and search. In about an hour I had gone to Splunk’s website to research the product, downloaded and installed it, and started viewing logs from my own system. The Splunk folks have made getting their product into their customer’s hands easy and getting started even easier.

What is Splunk?

Simply put, Splunk can gather just about any kind of data that goes into a log (system logs, website metrics, etc.) into one place and make viewing that data easy. It’s accessed via web browser so it’s accessible on any computer or mobile device such as an iPad.

What do I need to run Splunk?

Practically any common operating system today can run Splunk: Mac OS X, Linux, Windows, FreeBSD and more.

How much does Splunk cost?

Don’t worry about that right now. Download and install the free version. It takes minutes to install and is a no-brainer. Let’s get started.

Getting Splunk

IT managers and directors may be interested in watching the introductory and business case videos with the corporate speak (“operational intelligence” anyone?) and company endorsements. Techs will be interested in getting started. Right on their home page is a big green Free Download button. Go there, click it and locate the downloader for your OS of choice. I downloaded the Mac OS X 10.7 installer to test (and installed it on OS X 10.8 without any issues).

Splunk home

This does require a sign-up to create an account. It takes less than a minute to complete. After submitting the information the 100 MB download begins right away.

While waiting for the download…

When the download is on its way the Splunk folks kindly redirect to a page with some short videos to watch while waiting. Watch this first one called Getting data into Splunk. It’s only a few minutes and this is the first thing to do after getting into Splunk.

Installing and starting Splunk

The download arrives as a double-clickable Apple Installer package. Double-click and install it. Toward the end it opens a simple TextEdit window with instructions for how to start, stop and access the newly installed Splunk site.

Install done

Files are installed in /Applications/splunk and resemble a UNIX file system.

Splunk application folder

Open the Terminal application found in /Applications/Utilities and run the command /Applications/splunk/bin/splunk start. If this is the first time running Splunk it prompts to accept its license agreement. Tap the spacebar to scroll through and read the agreement or type “q” to quit and agree to the license.

EULA

Accepting the agreement continues to start Splunk where it displays some brief setup messages.

Starting Splunk

The setup then provides the local HTTP address for the newly installed Splunk site. Open this in a web browser to get to the login screen. The first login requires that the administrator account password be reset.

Splunk login

Following along with the Getting data into Splunk video, Splunk will need some information. Mac OS X stores its own log files. Let’s point to those.

Click the Add Data link to begin.

New Splunk home

Since Mac OS X’s log files are local to the machine, click A file or directory of files.

Add files

Click Next to specify local files.

Add local logs

This opens a window that exposes not only Mac OS X’s visible folders but its invisible folders as well. Browse to /var/log/system.log and click the Select button.

Browse logs folder

For now, opt to skip previewing the log file and click Continue.

Path to system.log

Now, let’s opt to monitor not only the system.log file but the entire /var/log folder containing dozens of other log files as well. Note that Splunk can watch rotated and zipped log files too. Click Save to finish adding logs.

Add /var/log folder

Let’s start searching!

Succes, start searching

The Search window initially displays a list of all logs Splunk is monitoring. To narrow the search change the time filter drop down menu to Last 60 minutes. This will make the results a little easier to see on a system that’s only been running a short while.

Last 24 hours

Now, search for install*. Splunk will only search for the word “install” without providing the asterisk as a wildcard character. Splunk supports not only wildcard searches but booleans, parentheses, quotes, etc. It will return every instance recorded in the logs that matches the search criteria. It also creates an interactive bar chart along the top of the page to indicate the number of occurrences found for the search at particular times.

Search for install

To further refine the search, Option+click most any word in the log entries below and Splunk will automatically add the necessary syntax to remove an item. In this case the install* search returned installinstaller and installd. Option+clicking installd changed the search criteria to install* NOT installd.

Modified search

Now what?

Continue exploring the videos to understand Splunk’s possibilities and take advantage of its Splunk Tutorial, which is available online as well as in PDF format for offline viewing. They do a great job leading users through setup and creating reports.

Still asking about price? Good.

The free version remains free but doesn’t include many features that really make it sing such as monitoring and alerts, multiple user accounts and support beyond the Splunk website. Cost depends primarily on the amount of data you want to suck into Splunk and have it watch. It’s not cheap but for an enterprise needing to meet certain service level requirements it beats browsing through multiple servers trying to find the right log with the right information.

FYI, putting together this 1,000-word article probably took me 10 times longer than performing the Splunk install itself and beginning to learn it. It’s really well-done and easy to use. Splunk makes getting started simple.

Emailing A File To Box.net

Wednesday, April 18th, 2012

Box.net has a number of features that can be used for workflow automation. One such feature is the ability to have an email address that is tied to a folder. Most services support the ability for that email address to be used to inform users of updates to directories. However, a somewhat unique feature is that Box.net has the ability to assign an email address to the folder so that any time you send mail to the folder, that file is added to the folder. For example, I scan a contract and email it to a vendor, I can also bcc a box.net folder called contracts and the contract will appear in the folder.

To setup an email address for a folder, open Box.net and click on a folder that you’d like to get an email address assigned to. Then click on the disclosure triangle on the right side of the screen for Folder Options and click on Email Options.

At the Email Options tab of the Folder Properties overlay screen, check the box for Allow uploads to this folder via email. Here, you can also use the Only allow uploads from collaborators in this folder checkbox to restrict who is able to email files to the folder.

While emailing files to get them into a folder isn’t for everyone, it is a great new take on a dropbox type of folder. You can also then sync these folders with folders in Mac OS X and Windows. This type of functionality is also a great way to do student submissions of coursework, file-based workflows for iOS and various automated workflows based on emails.

Lion, SSH And Special Characters

Tuesday, August 16th, 2011

At 318, we spend a pretty good bit of time SSH’d into Linux systems from Mac OS X. Therefore, whether we’re loosing our color settings when SSH’ing into Ubuntu or unable to transfer files via SSH, when OS X has a problem with Linux/SSH, we notice it pretty quickly. One such problem that has come up since we started moving many of our client systems over to Lion is that special characters don’t work by default when using SSH. Which is funny because they’re so much easier to type in Lion.

This is due to a small setting in /etc/ssh_config. To correct the setting, open ssh_config in your favorite text editor. Then look for the following line:

SendEnv LANG LC_*

Then remove LC_* from the line. I like to use the reset command any time I make such a change:

reset

BRU Server 2.0 Now Available

Friday, July 24th, 2009

BRU Server 2.0 was released this week, offering a long anticipated update to the popular cross platform backup suite of applications. The main two features that the TOLIS group is highlighting include Encryption of backup target sets and client initiated backup.

Whether you are a BRU, Atempo, Bakbone, Backup Exec or Retrospect environment, 318 can assist you with planning, testing, verifying or restoring backups. Contact your 318 account manager today for more details.

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.

#include

#include

#include

#include

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);

close(fh);

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));

close(fh);

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 "bsd.sb")

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= 4.2.2.2/domain 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/TextEdit.app/Contents/MacOS/TextEdit

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.