[SCAP-On-Apple-Dev] Configuration Profiles vs Plist file diddling
Shane Shaffer
shane.shaffer at g2-inc.com
Tue Jun 4 08:01:42 PDT 2013
While working with configuration profiles is likely the preferred
configuration mechanism moving forward (if one hasn't already invested in
another mechanism), the larger problem remains that there are multiple
mechanisms for configuring settings such as these, with unclear
relationships between those mechanisms and unclear behaviors within some
mechanisms. If only configuration profiles were used it seems to be a
relatively simple problem, but that's not realistic. We're dealing with
systems that might have a profile configured this way, might be managed via
Profile Manager, might have multiple conflicting .plist files across the
multitude of locations in the preferences hierarchy (all the by host, by
user, system wide, managed vs. local, etc. variants), and so on. Any
configuration method specific assessment mechanism is ultimately of little
value as long as multiple methods of configuration can be used.
I've previously gone down the road of attempting to understand the
hierarchy of .plist files and locations, but eventually realized that the
effective precedence hierarchy differs from setting to setting (not all
settings that may be configured in a plist file in one location are honored
if set by that same plist file in another location, and other differences),
and may be dependent on the state of the session lifecycle (i.e., one
precedence hierarchy is used at login that makes a managed preference
override a user level preference, but if the user can change the setting
during that session it may override the managed preference for the duration
of that session). Dealing with just plist files proved to be an impractical
assessment problem due to the inconsistent behaviors and lack of
documentation making it a frustrating trial and error effort.
What we really need is a definitive way to determine the effective
configuration of a setting regardless of configuration methods used. Sort
of an extended MCXCompositor behavior I suppose. A capability that does
this would be great for assessment, but to ensure proper remediation we
also need documentation of how all these configuration methods interact so
we can choose the most appropriate method and/or get the desired result
regardless of method chosen.
Shane Shaffer
G2, Inc.
shane.shaffer at g2-inc.com
On Mon, Jun 3, 2013 at 10:31 AM, Haynes, Dan <dhaynes at mitre.org> wrote:
> Reset! Thanks for the clarification, this definitely helps out and does
> sound much better than having to track down configuration files. With that
> said, I think configuration profiles are available starting in OSX 10.7?
> On previously versions of OSX, I think we will still need to deal with
> tracking down plist files. By any chance, is there a reference that maps
> OSX configuration settings to the corresponding plist files and preference
> keys?****
>
> ** **
>
> Also, we will take a pass at creating a new test around configuration
> profiles using the techniques you described below.****
>
>
> Thanks,
>
> Danny****
>
> ** **
>
> *From:* Josh Wisenbaker [mailto:dubs at apple.com]
> *Sent:* Friday, May 31, 2013 6:24 PM
> *To:* Haynes, Dan
> *Cc:* scap-on-apple-dev at lists.macosforge.org; OVAL
>
> *Subject:* Re: [SCAP-On-Apple-Dev] Configuration Profiles vs Plist file
> diddling****
>
> ** **
>
> 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****
>
> ** **
>
> On May 31, 2013, at 11:12 AM, "Haynes, Dan" <dhaynes at mitre.org> wrote:****
>
>
>
> ****
>
> Thanks for getting this discussion started Josh and Prabhu!****
>
> ****
>
> As Prahbu mentioned, we have the existing macos-def:plist510_test and the
> ind-def:xmlfilecontent_test that can support the assessment of plist files
> (including configuration profiles). There is also an experimental
> plist511_test in the OVAL Language Sandbox (
> https://github.com/OVALProject/Sandbox/blob/master/x-macos-plist-xpath.xsd)
> which utilizes xpath to reference the preference key of interest. ****
>
> ****
>
> To help show how these three tests can be used, I have attached sample
> definitions that check for CCE-28300-2 idle_time_for_screen_saver.****
>
> ****
>
> Hope this helps!****
>
>
> 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*Prabhu S Angadi
> *Sent:* Friday, May 31, 2013 3:38 AM
> *To:* scap-on-apple-dev at lists.macosforge.org
> *Subject:* Re: [SCAP-On-Apple-Dev] Configuration Profiles vs Plist file
> diddling****
>
> ****
>
> Hi All,
>
> Yes! I completely agree with Josh, on the usage configuration profiles.
>
> Being the XML formatted content of these files can be easily parsed to
> fetch the composed policies values, to develop the
> SCAP OVALl definitions, using available '< xmlfilecontent_test >' or '<
> plist510_test >' probes for better assessment.
>
> And also, as these files can be easily deployed with customized values as
> per user's choice. Either by
>
> * By physically connecting the device
> * In an email message
> * On a webpage
> * Using over-the air configuration as described in this document
>
> so I think it will be of great use in remediation part as well.
>
>
> _______________________________________________________________________________________
>
> In supportive to Josh, I have attached few Profile files, that were
> developed to address the Apple iOS Hardening Checklists
> by The University Of Texas at Austin.
>
> FMI :
>
> https://wikis.utexas.edu/display/ISO/Apple+iOS+Hardening+Checklist
>
> https://wikis.utexas.edu/display/ISO/iOS+Configuration+Profiles
>
>
> --
> Thanks !!
> Prabhu S A
>
> http://www.scaprepo.com
>
>
> ****
>
> On 05/31/2013 02:50 AM, Josh Wisenbaker wrote:****
>
> Hi all,****
>
> ****
>
> I think that from an audit and remediation standpoint things can be
> greatly simplified by using Configuration Profiles.****
>
> ****
>
> You can easily get a XML formatted list of the composited policies that
> are on the Mac and you can easily apply settings by installing a profile.
> Using the policy mechanisms in OS X is highly recommended over messing with
> files.****
>
> ****
>
> As an example here is a profile I made that implements all of the settings
> for the initial loginwindow tickets that are in the tracker.****
>
> ****
>
>
>
>
> ****
>
> ****
>
> This profile allows for removal without authentication so it's easy to
> test with.****
>
> ****
>
> Thoughts?****
>
> Josh****
>
> ****
>
> -- ****
>
> Josh Wisenbaker****
>
> Consulting Engineer - Apple U.S. Commercial and Governmental Sales****
>
> dubs at apple.com****
>
> ****
>
>
>
>
>
> ****
>
> _______________________________________________****
>
> SCAP-On-Apple-Dev mailing list****
>
> SCAP-On-Apple-Dev at lists.macosforge.org****
>
> https://lists.macosforge.org/mailman/listinfo/scap-on-apple-dev****
>
>
> <plist510_test_example.xml><plist511_test_example.xml><xmlfilecontent_test_example.xml>_______________________________________________
> SCAP-On-Apple-Dev mailing list
> SCAP-On-Apple-Dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/scap-on-apple-dev****
>
> ** **
>
> _______________________________________________
> SCAP-On-Apple-Dev mailing list
> SCAP-On-Apple-Dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/scap-on-apple-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/scap-on-apple-dev/attachments/20130604/4a386522/attachment-0001.html>
More information about the SCAP-On-Apple-Dev
mailing list