RE: Re: Chef's sudo cookbook and the passwordless access


#1

I don’t think using the sudoers.d directory is a good idea, because it is a security problem. There are two specific issues with it.

First, a hacker may be able to add his own file to the sudoers.d directory. That would be a classic injection/privilege escalation attack. Granted, it’s a bit more difficult because /etc/sudoers.d has permissions restricting it to root, but since it is also managed by chef, there can still be ways for a non-root user to insert a file into this directory.

The bigger issue is that there is no good way to automatically clean up obsolete entries from the sudoers.d directory; you may end up giving sudo access to people who should no longer have it.

From a security standpoint, it is dramatically better to only have a sudoers file and no include statement, especially not an include of a directory.

Kevin Keane

The NetTech

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html

-----Original message-----
From: tayworm . tayworm@gmail.com
Sent: Friday 13th March 2015 13:03
To: chef@lists.opscode.com
Subject: [chef] Re: Chef’s sudo cookbook and the passwordless access

A better way to use the cookbook would be to create files in sudoers.d for each entry. https://github.com/opscode-cookbooks/sudo#lwrp

On Fri, Mar 13, 2015 at 8:52 AM, Jimmy Huang <jimmy.huang@duragility.com mailto:jimmy.huang@duragility.com > wrote:
Hi,

I am trying to figure out how best to use the sudo cookbook. My cookbook is called masterwrap.

Berkesfile:

source “https://supermarket.chef.io

metadata

masterwrap/metadata.rb:

name 'masterwrap’
maintainer 'The Authors’
maintainer_email 'you@example.com mailto:you@example.com '
license 'all_rights’
description 'Installs/Configures masterwrap’
long_description 'Installs/Configures masterwrap’
version ‘0.1.0’

depends ‘git’, '~> 4.1.0’
depends ‘sudo’, '~> 2.7.1’
depends ‘users’, ‘~> 1.8.0’

masterwrap/recipes/default.rb:

Cookbook Name:: masterwrap

Recipe:: default

Copyright © 2015 The Authors, All Rights Reserved.

include_recipe 'git’
include_recipe ‘masterwrap::users’

masterwrap/recipes/users.rb:

Cookbook Name:: masterwrap

Recipe:: users

Copyright © 2015 The Authors, All Rights Reserved.

include_recipe 'sudo’
include_recipe ‘users’

%w(deploy sysadmin).each do |group|
users_manage group do
data_bag 'users’
action [ :remove, :create ]
end
end

sudo ‘sysadmin’ do
group '%sysadmin’
nopasswd false
end

If I converge at this point, my vagrant user would stop having passwordless sudo access. To make sure that does not happen, I have the following masterwrap/.kitchen.yml file:


driver:
name: vagrant

provisioner:
name: chef_zero

platforms:

  • name: ubuntu1404
    driver:
    box: ubuntu/trusty64
    box_url: ubuntu/trusty64
    attributes:
    authorization:
    sudo:
    users: [‘vagrant’]
    passwordless: true
    include_sudoers_d: true

suites:

  • name: default
    data_bags_path: 'test/fixtures/data_bags’
    run_list:
    • recipe[masterwrap::default]
      attributes:

The problem is that I DO want a password prompt for my sudo access for non-vagrant users, but I am not sure how to go about achieving that. Here is my current /etc/sudoers file after the converge:

This file is managed by Chef.

Do NOT modify this file directly.

Defaults !lecture,tty_tickets,!fqdn

User privilege specification

root ALL=(ALL) ALL

vagrant ALL=(ALL) NOPASSWD:ALL

Members of the group ‘sysadmin’ may gain root privileges

%sysadmin ALL=(ALL) NOPASSWD:ALL

===

Given the node’s structure, I think the sudo cookbook assumes everyone who is granted sudo access via the cookbook will want the same setting for passwordless, which is not the desired outcome in my case. Is there a way around this assumption or a better way for me to use the sudo cookbook? Thank you for your help.

Sincerely,
Jimmy


#2

He ready has include_sudoers_d: true in his attributes, so he might as well use it. Managing the entries is something that could easily be done in a wrapper cookbook.

On Mar 14, 2015, at 10:24 PM, Kevin Keane Subscription subscription@kkeane.com wrote:

I don’t think using the sudoers.d directory is a good idea, because it is a security problem. There are two specific issues with it.

First, a hacker may be able to add his own file to the sudoers.d directory. That would be a classic injection/privilege escalation attack. Granted, it’s a bit more difficult because /etc/sudoers.d has permissions restricting it to root, but since it is also managed by chef, there can still be ways for a non-root user to insert a file into this directory.

The bigger issue is that there is no good way to automatically clean up obsolete entries from the sudoers.d directory; you may end up giving sudo access to people who should no longer have it.

From a security standpoint, it is dramatically better to only have a sudoers file and no include statement, especially not an include of a directory.

Kevin Keane

The NetTech

http://www.4nettech.com
Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html

-----Original message-----
From: tayworm . tayworm@gmail.com
Sent: Friday 13th March 2015 13:03
To: chef@lists.opscode.com
Subject: [chef] Re: Chef’s sudo cookbook and the passwordless access

A better way to use the cookbook would be to create files in sudoers.d for each entry. https://github.com/opscode-cookbooks/sudo#lwrp

On Fri, Mar 13, 2015 at 8:52 AM, Jimmy Huang jimmy.huang@duragility.com wrote:

Hi,

I am trying to figure out how best to use the sudo cookbook. My cookbook is called masterwrap.

Berkesfile:

source “https://supermarket.chef.io

metadata

masterwrap/metadata.rb:

name 'masterwrap’
maintainer 'The Authors’
maintainer_email 'you@example.com’
license 'all_rights’
description 'Installs/Configures masterwrap’
long_description 'Installs/Configures masterwrap’
version ‘0.1.0’

depends ‘git’, '~> 4.1.0’
depends ‘sudo’, '~> 2.7.1’
depends ‘users’, ‘~> 1.8.0’

masterwrap/recipes/default.rb:

Cookbook Name:: masterwrap

Recipe:: default

Copyright © 2015 The Authors, All Rights Reserved.

include_recipe 'git’
include_recipe ‘masterwrap::users’

masterwrap/recipes/users.rb:

Cookbook Name:: masterwrap

Recipe:: users

Copyright © 2015 The Authors, All Rights Reserved.

include_recipe 'sudo’
include_recipe ‘users’

%w(deploy sysadmin).each do |group|
users_manage group do
data_bag 'users’
action [ :remove, :create ]
end
end

sudo ‘sysadmin’ do
group '%sysadmin’
nopasswd false
end

If I converge at this point, my vagrant user would stop having passwordless sudo access. To make sure that does not happen, I have the following masterwrap/.kitchen.yml file:


driver:
name: vagrant

provisioner:
name: chef_zero

platforms:

  • name: ubuntu1404
    driver:
    box: ubuntu/trusty64
    box_url: ubuntu/trusty64
    attributes:
    authorization:
    sudo:
    users: [‘vagrant’]
    passwordless: true
    include_sudoers_d: true

suites:

  • name: default
    data_bags_path: 'test/fixtures/data_bags’
    run_list:
    • recipe[masterwrap::default]
      attributes:
      The problem is that I DO want a password prompt for my sudo access for non-vagrant users, but I am not sure how to go about achieving that. Here is my current /etc/sudoers file after the converge:

This file is managed by Chef.

Do NOT modify this file directly.

Defaults !lecture,tty_tickets,!fqdn

User privilege specification

root ALL=(ALL) ALL

vagrant ALL=(ALL) NOPASSWD:ALL

Members of the group ‘sysadmin’ may gain root privileges

%sysadmin ALL=(ALL) NOPASSWD:ALL

===

Given the node’s structure, I think the sudo cookbook assumes everyone who is granted sudo access via the cookbook will want the same setting for passwordless, which is not the desired outcome in my case. Is there a way around this assumption or a better way for me to use the sudo cookbook? Thank you for your help.

Sincerely,
Jimmy


#3

Its not exactly impossible to enforce strict cleanup of the sudoers.d
directory with Chef.

Just do some set arithmetic. Given a set of entries that are expected to
be created, and given a directory listing of sudoers.d, one can determine
the set of entries which need cleaned up.

(cleanup set) = (dir listing) - (managed set of entries)


#4

On 3/14/15 10:24 PM, Kevin Keane Subscription wrote:

RE: [chef] Re: Chef’s sudo cookbook and the passwordless access

I don’t think using the sudoers.d directory is a good idea, because it
is a security problem. There are two specific issues with it.

First, a hacker may be able to add his own file to the sudoers.d
directory. That would be a classic injection/privilege escalation
attack. Granted, it’s a bit more difficult because /etc/sudoers.d has
permissions restricting it to root, but since it is also managed by
chef, there can still be ways for a non-root user to insert a file
into this directory.

If an attacker can create a file in /etc/sudoers.d with arbitrary
content they can also create a file in /etc/cron.d with arbitrary
content and run a command as root via cron to give them a backdoor.

The bigger issue is that there is no good way to automatically clean
up obsolete entries from the sudoers.d directory; you may end up
giving sudo access to people who should no longer have it.

That’s a solvable problem. The zap cookbook is one way.

From a security standpoint, it is dramatically better to only have a
sudoers file and no include statement, especially not an include of a
directory.

Kevin Keane

The NetTech

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html

-----Original message-----
*From:* tayworm . <tayworm@gmail.com>
*Sent:* Friday 13th March 2015 13:03
*To:* chef@lists.opscode.com
*Subject:* [chef] Re: Chef's sudo cookbook and the passwordless access

A better way to use the cookbook would be to create files in
sudoers.d for each entry.
https://github.com/opscode-cookbooks/sudo#lwrp

On Fri, Mar 13, 2015 at 8:52 AM, Jimmy Huang
<jimmy.huang@duragility.com <mailto:jimmy.huang@duragility.com>>
wrote:

    Hi,

    I am trying to figure out how best to use the sudo cookbook. 
    My cookbook is called masterwrap.

    Berkesfile:

    source "https://supermarket.chef.io"

    metadata


    masterwrap/metadata.rb:

    name'masterwrap'
    maintainer'The Authors'
    maintainer_email'you@example.com  <mailto:you@example.com>'
    license'all_rights'
    description'Installs/Configures masterwrap'
    long_description'Installs/Configures masterwrap'
    version'0.1.0'

    depends'git','~> 4.1.0'
    depends'sudo','~> 2.7.1'
    depends'users','~> 1.8.0'


    masterwrap/recipes/default.rb:

    #
    # Cookbook Name:: masterwrap
    # Recipe:: default
    #
    # Copyright (c) 2015 The Authors, All Rights Reserved.

    include_recipe'git'
    include_recipe'masterwrap::users'


    masterwrap/recipes/users.rb:

    #
    # Cookbook Name:: masterwrap
    # Recipe:: users
    #
    # Copyright (c) 2015 The Authors, All Rights Reserved.

    include_recipe'sudo'
    include_recipe'users'

    %w(deploy sysadmin).eachdo |group|
       users_manage groupdo
         data_bag'users'
         action [:remove,:create]
       end
    end

    sudo'sysadmin'do
       group'%sysadmin'
       nopasswdfalse
    end


    If I converge at this point, my vagrant user would stop having
    passwordless sudo access.  To make sure that does not happen,
    I have the following masterwrap/.kitchen.yml file:

    ---
    driver:
       name:vagrant

    provisioner:
       name:chef_zero

    platforms:
       -name:ubuntu1404
         driver:
           box:ubuntu/trusty64
           box_url:ubuntu/trusty64
         attributes:
           authorization:
             sudo:
               users:['vagrant']
               passwordless:true
               include_sudoers_d:true

    suites:
       -name:default
         data_bags_path:'test/fixtures/data_bags'
         run_list:
           -recipe[masterwrap::default]
         attributes:

    The problem is that I DO want a password prompt for my sudo
    access for non-vagrant users, but I am not sure how to go
    about achieving that.  Here is my current /etc/sudoers file
    after the converge:

    # This file is managed by Chef.

    # Do NOT modify this file directly.

    Defaults      !lecture,tty_tickets,!fqdn

    # User privilege specification

    root          ALL=(ALL) ALL

    vagrant ALL=(ALL) NOPASSWD:ALL

    # Members of the group 'sysadmin' may gain root privileges

    %sysadmin ALL=(ALL) NOPASSWD:ALL

    ===

    Given the node's structure, I think the sudo cookbook assumes
    everyone who is granted sudo access via the cookbook will want
    the same setting for passwordless, which is not the desired
    outcome in my case.  Is there a way around this assumption or
    a better way for me to use the sudo cookbook?  Thank you for
    your help.

    Sincerely,
    Jimmy