saltstack/salt
1
0
Fork 0
mirror of https://github.com/saltstack/salt.git synced 2025-04-17 10:10:20 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

Merge branch '2016.11' into 2016.11-fix-2291

Browse source
This commit is contained in:
Mike Place 2017-10-09 17:10:16 -06:00 • committed by GitHub
commit a81b78381b
8 changed files with 77 additions and 29 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/conf.py
View file

@ -240,8 +240,8 @@ on_saltstack = 'SALT_ON_SALTSTACK' in os.environ
project = 'Salt'
version = salt.version.__version__
latest_release = '2017.7.1' # latest release
previous_release = '2016.11.7' # latest release from previous branch
latest_release = '2017.7.2' # latest release
previous_release = '2016.11.8' # latest release from previous branch
previous_release_dir = '2016.11' # path on web server for previous branch
next_release = '' # next release
next_release_dir = '' # path on web server for next release branch

7
doc/topics/eauth/index.rst
View file

@ -218,6 +218,7 @@ Server configuration values and their defaults:
# Bind to LDAP anonymously to determine group membership
# Active Directory does not allow anonymous binds without special configuration
# In addition, if auth.ldap.anonymous is True, empty bind passwords are not permitted.
auth.ldap.anonymous: False
# FOR TESTING ONLY, this is a VERY insecure setting.
@ -250,7 +251,11 @@ and groups, it re-authenticates as the user running the Salt commands.
If you are already aware of the structure of your DNs and permissions in your LDAP store are set such that
users can look up their own group memberships, then the first and second users can be the same. To tell Salt this is
the case, omit the ``auth.ldap.bindpw`` parameter. You can template the ``binddn`` like this:
the case, omit the ``auth.ldap.bindpw`` parameter. Note this is not the same thing as using an anonymous bind.
Most LDAP servers will not permit anonymous bind, and as mentioned above, if `auth.ldap.anonymous` is False you
cannot use an empty password.
You can template the ``binddn`` like this:
.. code-block:: yaml

12
doc/topics/releases/2016.11.8.rst
View file

@ -4,9 +4,21 @@ Salt 2016.11.8 Release Notes
Version 2016.11.8 is a bugfix release for :ref:`2016.11.0 <release-2016-11-0>`.]
Anonymous Binds and LDAP/Active Directory
-----------------------------------------
When auth.ldap.anonymous is set to False, the bind password can no longer be empty.
Changes for v2016.11.7..v2016.11.8
----------------------------------
Security Fix
============
CVE-2017-14695 Directory traversal vulnerability in minion id validation in SaltStack. Allows remote minions with incorrect credentials to authenticate to a master via a crafted minion ID. Credit for discovering the security flaw goes to: Julian Brost (julian@0x4a42.net)
CVE-2017-14696 Remote Denial of Service with a specially crafted authentication request. Credit for discovering the security flaw goes to: Julian Brost (julian@0x4a42.net)
Extended changelog courtesy of Todd Stansell (https://github.com/tjstansell/salt-changelogs):
*Generated at: 2017-09-11T14:52:27Z*

22
doc/topics/releases/2016.3.8.rst
View file

@ -7,23 +7,9 @@ Version 2016.3.8 is a bugfix release for :ref:`2016.3.0 <release-2016-3-0>`.
Changes for v2016.3.7..v2016.3.8
--------------------------------
New master configuration option `allow_minion_key_revoke`, defaults to True. This option
controls whether a minion can request that the master revoke its key. When True, a minion
can request a key revocation and the master will comply. If it is False, the key will not
be revoked by the msater.
Security Fix
============
New master configuration option `require_minion_sign_messages`
This requires that minions cryptographically sign the messages they
publish to the master. If minions are not signing, then log this information
at loglevel 'INFO' and drop the message without acting on it.
CVE-2017-14695 Directory traversal vulnerability in minion id validation in SaltStack. Allows remote minions with incorrect credentials to authenticate to a master via a crafted minion ID. Credit for discovering the security flaw goes to: Julian Brost (julian@0x4a42.net)
New master configuration option `drop_messages_signature_fail`
Drop messages from minions when their signatures do not validate.
Note that when this option is False but `require_minion_sign_messages` is True
minions MUST sign their messages but the validity of their signatures
is ignored.
New minion configuration option `minion_sign_messages`
Causes the minion to cryptographically sign the payload of messages it places
on the event bus for the master. The payloads are signed with the minion's
private key so the master can verify the signature with its public key.
CVE-2017-14696 Remote Denial of Service with a specially crafted authentication request. Credit for discovering the security flaw goes to: Julian Brost (julian@0x4a42.net)

29
doc/topics/releases/2016.3.9.rst Normal file
View file

@ -0,0 +1,29 @@
===========================
Salt 2016.3.9 Release Notes
===========================
Version 2016.3.9 is a bugfix release for :ref:`2016.3.0 <release-2016-3-0>`.
Changes for v2016.3.7..v2016.3.9
--------------------------------
New master configuration option `allow_minion_key_revoke`, defaults to True. This option
controls whether a minion can request that the master revoke its key. When True, a minion
can request a key revocation and the master will comply. If it is False, the key will not
be revoked by the msater.
New master configuration option `require_minion_sign_messages`
This requires that minions cryptographically sign the messages they
publish to the master. If minions are not signing, then log this information
at loglevel 'INFO' and drop the message without acting on it.
New master configuration option `drop_messages_signature_fail`
Drop messages from minions when their signatures do not validate.
Note that when this option is False but `require_minion_sign_messages` is True
minions MUST sign their messages but the validity of their signatures
is ignored.
New minion configuration option `minion_sign_messages`
Causes the minion to cryptographically sign the payload of messages it places
on the event bus for the master. The payloads are signed with the minion's
private key so the master can verify the signature with its public key.

4
salt/auth/ldap.py
View file

@ -110,6 +110,10 @@ class _LDAPConnection(object):
self.ldap.set_option(ldap.OPT_REFERRALS, 0) # Needed for AD
if not anonymous:
if self.bindpw is None or len(self.bindpw) < 1:
raise CommandExecutionError(
'LDAP bind password is not set: password cannot be empty if auth.ldap.anonymous is False'
)
self.ldap.simple_bind_s(self.binddn, self.bindpw)
except Exception as ldap_error:
raise CommandExecutionError(

7
salt/modules/grains.py
View file

@ -121,7 +121,7 @@ def get(key, default='', delimiter=DEFAULT_TARGET_DELIM, ordered=True):
def has_value(key):
'''
Determine whether a named value exists in the grains dictionary.
Determine whether a key exists in the grains dictionary.
Given a grains dictionary that contains the following structure::
@ -137,7 +137,10 @@ def has_value(key):
salt '*' grains.has_value pkg:apache
'''
return True if salt.utils.traverse_dict_and_list(__grains__, key, False) else False
return salt.utils.traverse_dict_and_list(
__grains__,
key,
KeyError) is not KeyError
def items(sanitize=False):

21
salt/states/zenoss.py
View file

@ -6,7 +6,7 @@ State to manage monitoring in Zenoss.
This state module depends on the 'zenoss' Salt execution module.
Allows for setting a state of minions in Zenoss using the Zenoss API. Currently Zenoss 4.x is supported.
Allows for setting a state of minions in Zenoss using the Zenoss API. Currently Zenoss 4.x and 5.x are supported.
.. code-block:: yaml
@ -30,6 +30,8 @@ def __virtual__():
'''
if 'zenoss.add_device' in __salt__:
return 'zenoss'
else:
return False, "The zenoss execution module is not available"
def monitored(name, device_class=None, collector='localhost', prod_state=None):
@ -57,21 +59,28 @@ def monitored(name, device_class=None, collector='localhost', prod_state=None):
ret['comment'] = '{0} is already monitored'.format(name)
# if prod_state is set, ensure it matches with the current state
if prod_state:
if device['productionState'] != prod_state:
if prod_state is not None and device['productionState'] != prod_state:
if __opts__['test']:
ret['comment'] = '{0} is already monitored but prodState will be updated'.format(name)
ret['result'] = None
else:
__salt__['zenoss.set_prod_state'](prod_state, name)
ret['changes'] = {'old': 'prodState == {0}'.format(device['productionState']), 'new': 'prodState == {0}'.format(prod_state)}
ret['comment'] = '{0} is already monitored but prodState was incorrect, setting to Production'.format(name)
ret['comment'] = '{0} is already monitored but prodState was updated'.format(name)
ret['changes'] = {
'old': 'prodState == {0}'.format(device['productionState']),
'new': 'prodState == {0}'.format(prod_state)
}
return ret
# Device not yet in Zenoss
if __opts__['test']:
ret['comment'] = 'The state of "{0}" will be changed.'.format(name)
ret['changes'] = {'old': 'monitored == False', 'new': 'monitored == True'}
ret['result'] = None
return ret
# Device not yet in Zenoss. Add and check result
# Add and check result
if __salt__['zenoss.add_device'](name, device_class, collector, prod_state):
ret['result'] = True
ret['changes'] = {'old': 'monitored == False', 'new': 'monitored == True'}