New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chef user resource for macOS is not compatible with macOS 10.14 security protections #7763

Open
pudquick opened this Issue Oct 19, 2018 · 7 comments

Comments

Projects
None yet
2 participants
@pudquick

pudquick commented Oct 19, 2018

Description

The user resource as currently designed for macOS performs operations which are blocked in 10.14 by default.

Chef Version

This affects all versions, but the examples I'll give here are for 14.3.37

Platform Version

macOS 10.14 (Mojave) build 18A391

Replication Case

Create a user resource:

user '_example' do
  comment 'example user'
  system true
  shell '/usr/bin/false'
  home '/var/empty'
  action :create
end

Run chef once. No errors will occur. Run it again, chef will terminate with an error.

Client Output

================================================================================
      Error executing action `create` on resource 'dscl_user[_example]'
================================================================================
      
      Chef::Exceptions::DsclCommandFailed
      -----------------------------------
      dscl error: <Mixlib::ShellOut#70108986308720: command: '["dscl", ".", "-create", "/Users/_example", "UniqueID", "206"]' process_status: #<Process::Status: pid 8590 exit 40> stdout: '' stderr: '<main> attribute status: eDSPermissionError
      <dscl_cmd> DS Error: -14120 (eDSPermissionError)' child_pid: 8590 environment: {"LC_ALL"=>"en_US.UTF-8", "LANGUAGE"=>"en_US.UTF-8", "LANG"=>"en_US.UTF-8", "PATH"=>"[clipped for brevity]"} timeout: 600 user:  group:  working_dir:  >

...

    System Info:
    ------------
    chef_version=14.3.37
    platform=mac_os_x
    platform_version=10.14
    ruby=ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin15]
    program_name=/usr/local/bin/chef-client
    executable=/opt/chef/bin/chef-client

@pudquick

This comment has been minimized.

pudquick commented Oct 19, 2018

Root cause for this lies in several behaviors the chef resource performs which are now denied by default on macOS 10.14.

For example:
https://github.com/chef/chef/blob/master/lib/chef/provider/user/dscl.rb#L592-L594

            user_plist_file = "#{USER_PLIST_DIRECTORY}/#{new_resource.username}.plist"
            user_plist_info = run_plutil("convert", "xml1", "-o", "-", user_plist_file)
            user_info = Plist.parse_xml(user_plist_info)

Direct file access of the dslocal plists are now denied by the new privacy protections in 10.14. All user information access must be done via OS APIs or tools that make use of these native APIs. This means that read_user_info fails and returns nil for the values of a user.

So in the example above, creation works on the first run because it goes through dscl and creates the attributes.

But on the second run, it sees that the user exists (dscl is run to find it, which is fine) but thinks that all the attributes are nil (the plist is attempted to be read directly, which is denied). As a result, it thinks the resource has diverged and will attempt to re-set values and fails on the UID (attempting to change the UID of an existing user is also protected).

@pudquick

This comment has been minimized.

pudquick commented Oct 19, 2018

There are deeper problems with the resource as well.

If you want to set a password, the password operation is also done via direct plist access. All password operations are disallowed under 10.14 as a result.

When you remove a user resource, it attempts to clean up the home directory with remove_user:
https://github.com/chef/chef/blob/master/lib/chef/provider/user/dscl.rb#L444

If the account that was created with chef was ever logged into and Apple Mail was used, it will make a ~/Library/Mail directory in the user's home folder which also falls under Mojave's new privacy security protections and recursive removal of the directory is denied.

@pudquick

This comment has been minimized.

pudquick commented Oct 19, 2018

We have some monkey patching which corrects much of this - but for issues like remove_user ... I'm not sure what the best path forward here is.

For an overview of the Mojave privacy protections, this is a good writeup: https://carlashley.com/2018/09/28/tcc-round-up/

There's a management functionality for this on macOS, but it requires not just MDM management of the Mac but also DEP/UAMDM enabled MDM - before a configuration profile like the one in the blog post can be deployed to the machine to make chef runs work again.

Additionally, to get these protections - part of chef for macOS will need to be codesigned. Is chef interested in doing this? Will organizations be expected to do this?

@pudquick

This comment has been minimized.

@erikng

This comment has been minimized.

Contributor

erikng commented Oct 20, 2018

+1 for chef signing their binaries. We have some internal requests for that, but I thought it was an unrealistic ask for us to fork chef to sign the binaries.

@pudquick

This comment has been minimized.

pudquick commented Oct 20, 2018

I would agree that organizations performing the signing themselves would probably make sustainability of upgrades / rollout of client upgrades more difficult - basically a pretty decent impediment to adoption of chef on macOS 10.14+ as a whole.

@pudquick

This comment has been minimized.

pudquick commented Oct 20, 2018

Alternative to the monkey patching I provided: if chef wanted to use native APIs for user operations, that would also eliminate a lot of problems. You can see the hoops I had to jump through to make set_password work with dsimport.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment