File: rule.yml

package info (click to toggle)
scap-security-guide 0.1.78-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 114,600 kB
  • sloc: xml: 245,305; sh: 84,381; python: 33,093; makefile: 27
file content (43 lines) | stat: -rw-r--r-- 2,050 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
documentation_complete: true

title: "Don't define allowed commands in sudoers by means of exclusion"

description: |-
    Policies applied by sudo through the sudoers file should not involve negation.

    Each user specification in the <code>sudoers</code> file contains a comma-delimited list of command specifications.
    The definition can make use glob patterns, as well as of negations.
    Indirect definition of those commands by means of exclusion of a set of commands is trivial to bypass, so it is not allowed to use such constructs.

rationale: |-
    Specifying access right using negation is inefficient and can be easily circumvented.
    For example, it is expected that a specification like <pre>
    # To avoid absolutely , this rule can be easily circumvented!
    user ALL = ALL ,!/ bin/sh
    </pre> prevents the execution of the shell
    but that’s not the case: just copy the binary <code>/bin/sh</code> to a different name to make it executable
    again through the rule keyword <code>ALL</code>.

severity: medium

identifiers:
    cce@rhel8: CCE-83518-1
    cce@rhel9: CCE-83524-9
    cce@rhel10: CCE-90660-2
    cce@sle12: CCE-91502-5
    cce@sle15: CCE-91193-3

ocil_clause: '/etc/sudoers file contains rules that define the set of allowed commands using negation'

# A setp-by-step guide how to modify the configuration to achieve compliance
ocil: |-
    To determine if negation is used to define commands users are allowed to execute using <tt>sudo</tt>, run the following command:
    <pre>$ sudo grep -PR '^(?:\s*[^#=]+)=(?:\s*(?:\([^\)]+\))?\s*(?!\s*\()[^,!\n][^,\n]+,)*\s*(?:\([^\)]+\))?\s*(?!\s*\()(!\S+).*' /etc/sudoers /etc/sudoers.d/</pre>
    The command should return no output.

platform: package[sudo]

warnings:
  - general:
      This rule doesn't come with a remediation, as negations indicate design issues with the sudoers user specifications design.
      Just removing negations doesn't increase the security - you typically have to rethink the definition of allowed commands to fix the issue.