[SCAP-On-Apple-Dev] Configuration Profiles vs Plist file diddling
Haynes, Dan
dhaynes at mitre.org
Mon Jun 3 07:36:29 PDT 2013
Hi David,
Thanks for cross-posting this message! I agree it makes sense to create a test around profiles that is similar to the plist511_test. We will take a pass at putting such a test together and we will put it in the sandbox for review and discussion.
Thanks,
Danny
From: scap-on-apple-dev-bounces at lists.macosforge.org [mailto:scap-on-apple-dev-bounces at lists.macosforge.org] On Behalf Of David Solin
Sent: Saturday, June 01, 2013 12:57 PM
To: scap-on-apple-dev at lists.macosforge.org
Subject: Re: [SCAP-On-Apple-Dev] Configuration Profiles vs Plist file diddling
(I cross-posted the message below to the OVAL developer list, but had to trim it to under 40k and re-post for this list)
It sounds like, since the profile information is not resident on disk in the form of a plist, XML or text file, there's a need for a new test in the OVAL Mac schema -- a i.e., a profile_test, which would extract the profile as described below. Such a test could be designed like the upcoming plist511_test, to use XPATH to query the profile.
If so, I would strongly urge interested parties to bring such a recommendation to the attention of the OVAL board, so that it will be possible to create useful SCAP content by the time OVAL 5.11 is finalized. Otherwise, an even longer wait will be ahead of us all.
Regards,
--David Solin
-------- Original Message --------
Subject:
Re: [SCAP-On-Apple-Dev] Configuration Profiles vs Plist file diddling
Date:
Fri, 31 May 2013 18:24:27 -0400
From:
Josh Wisenbaker <dubs at apple.com><mailto:dubs at apple.com>
To:
Haynes, Dan <dhaynes at mitre.org><mailto:dhaynes at mitre.org>
CC:
scap-on-apple-dev at lists.macosforge.org<mailto:scap-on-apple-dev at lists.macosforge.org> <scap-on-apple-dev at lists.macosforge.org><mailto:scap-on-apple-dev at lists.macosforge.org>, OVAL <oval at mitre.org><mailto:oval at mitre.org>
I think that there needs to be a bit of a mental reset as to how to validate settings on the Mac as checking on-disk files doesn't actually verify much and it really hasn't for some time now. For example let's take a look at the loginwindow settings. The current tests would look at a file to see if the settings are there.
On my test Mac I have the test profile that I made installed. Because I'm doing things with policy, it doesn't exist in the plists or domains.
server:~ localadmin$ defaults -currentHost read com.apple.loginwindow
{
TALAppsToRelaunchAtLogin = (
{
BackgroundState = 2;
BundleID = "com.apple.terminal";
Hide = 0;
Path = "/Applications/Utilities/Terminal.app";
},
{
BackgroundState = 2;
BundleID = "com.apple.finder";
Hide = 0;
Path = "/System/Library/CoreServices/Finder.app";
}
);
}
Lets try another!
server:~ localadmin$ defaults read /Library/Preferences/com.apple.loginwindow.plist
{
OptimizerLastRunForBuild = 25364928;
OptimizerLastRunForSystem = 168297216;
lastUser = loggedIn;
lastUserName = localadmin;
}
Hmm. Not there either. Maybe just the basic domain?
server:~ localadmin$ defaults read com.apple.loginwindow
{
TALLogoutReason = Restart;
}
No. Not there either! Well crap. Logging out though shows me that the settings are applied!
I can't really check the mobileconfig files either since they get turned into a binary blob upon installation in /var/db/ConfigurationProfiles/Store
So what can I do?
Well the first thing is that we can ask if there are profiles installed!
server:~ localadmin$ profiles -H
profiles are installed on this system
Sweet! But now what?
Now we actually have several options, the easiest is to grab the profile data right from the profiles command as XML. You can also get this from system_profiler, and if you are using directory services based policy you can get it from dscl or mcxquerey as well.
server:~ localadmin$ sudo profiles -Pv -o Output.xml
profiles: verbose mode ON
profiles: outputPath = Output.xml
There are 1 configuration profiles installed
pass
server:~ localadmin$ less Output.xml
SNIP...
<dict>
<key>PayloadContent</key>
<dict>
<key>loginWindowIdleTime</key>
<integer>900</integer>
<key>loginWindowModulePath</key>
<string>/System/Library/Screen Savers/Flurry.saver</string>
</dict>
<key>PayloadDisplayName</key>
<string>Login Window: Screen Saver Preferences</string>
<key>PayloadIdentifier</key>
<string>com.apple.mdm.server.example.private.a55249a0-ab8d-0130-272f-001c42d3e5bf.alacarte.loginwindow.6e51c520-ab8e-0130-2731-001c42d3e5bf.screensaver</string>
<key>PayloadType</key>
<string>com.apple.screensaver</string>
<key>PayloadUUID</key>
<string>42a5182d-2af5-dfa8-16b8-d3a3a88c37fb</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
...SNIP
As we can see, the only way to tell if this policy has been applied with a modern method like a configuration profile is to check using tools that are configuration profile aware.
For settings that use profiles this makes everything much simpler. You can simply ask for the output of the profiles command and then parse it with XPath or what not. You get all the settings in one place and you don't need to run around tracking down config files.
Thanks,
Josh
--
Josh Wisenbaker
Consulting Engineer - Apple U.S. Commercial and Governmental Sales
dubs at apple.com<mailto:dubs at apple.com>
--
jOVAL.org: SCAP Simplified.
Learn More<http://www.joval.org> | Features<http://www.joval.org/features/> | Download<http://www.joval.org/download/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/scap-on-apple-dev/attachments/20130603/b78110dc/attachment-0001.html>
More information about the SCAP-On-Apple-Dev
mailing list