Add interface similar to files_mountpoint() and add a conditional which
allows mount on non_security_file_type.
Signed-off-by: Chris PeBenito <chpebeni@linux.microsoft.com>
The implementation for NETLINK_FIREWALL and NETLINK_IP6_FW protocols
was removed from the kernel in commit
d16cf20e2f2f13411eece7f7fb72c17d141c4a84 ("netfilter: remove ip_queue
support") circa Linux 3.5. Consequently, kernels >= 3.5 should never
perform permission checks on these classes although they remained
defined in the SELinux kernel classmap until the netlink classes
were updated by
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6c6d2e9bde1c1c87a7ead806f8f5e2181d41a652
circa Linux v4.2.
Removing these class definitions would break legacy userspace that relies
upon stable values for the userspace security class definitions since it
will perturb those values by removing classes that preceded them. dbus-daemon
in particular is known to break if its dbus class changes at runtime,
which could occur upon a policy reload that removes these classes.
Fixing this requires ensuring that dbus-daemon looks up the appropriate
class value on each use or upon policy reload, via userspace interfaces
such as selinux_check_access(), string_to_security_class(), and/or
selinux_set_callback(SELINUX_CB_POLICYLOAD, ...) with a callback function
that remaps the class value if needed. Other userspace policy enforcers
are believed to have been updated in recent versions but older versions
may break upon such a change.
Hence, this change renames these classes with obsolete_ prefixes and
removes all rules referencing them from refpolicy, thereby preserving
the class numbering for subsequent classes while making it clear that
these classses are no longer meaningful for modern kernels.
This change does however create a potential compatibility break for
kernels < 3.5, since the policy will cease to define the kernel class
names and therefore the kernel will handle permission checks on the
class based on the handle_unknown setting in policy. For most
Linux distributions, this will default to allow and therefore avoid
breaking userspace but will fail open. For kernels < 2.6.33 (i.e.
the dynamic class/perm discovery support), the presence of a class
in policy with the same number but a different name than the kernel
class will cause the policy load to fail entirely.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
entrypoint and execute_no_trans permissions are only ever checked by the
kernel to regular files. They were added to the chr_file class when
execmod was added (which can be checked on chr_file) to ensure that it
was assigned the same value as for the file class, since the kernel code
always checked FILE__EXECMOD. However, the policy definitions are not
necessary since the kernel and policy values have been decoupled ever
since dynamic class/perm support was introduced and further with the
move of execmod to the common definitions, they were not even needed
in the kernel.
These were removed from the kernel's classmap by
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b424485abe2b16580a178b469917a7b6ee0c152a
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Remove unused permission definitions from SELinux.
Many of these were only ever used in pre-mainline
versions of SELinux, prior to Linux 2.6.0. Some of them
were used in the legacy network or compat_net=1 checks
that were disabled by default in Linux 2.6.18 and
fully removed in Linux 2.6.30.
The corresponding classmap declarations were removed from the
mainline kernel in:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=42a9699a9fa179c0054ea3cf5ad3cc67104a6162
Permissions never used in mainline Linux:
file swapon
filesystem transition
tcp_socket { connectto newconn acceptfrom }
node enforce_dest
unix_stream_socket { newconn acceptfrom }
Legacy network checks, removed in 2.6.30:
socket { recv_msg send_msg }
node { tcp_recv tcp_send udp_recv udp_send rawip_recv rawip_send dccp_recv dccp_send }
netif { tcp_recv tcp_send udp_recv udp_send rawip_recv rawip_send dccp_recv dccp_send }
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
As adding attribute fixed_disk_raw_read to a type cannot occur in a
conditional statement, create a new interface that takes a tunable as
parameter to allow a dangerous access conditionally.
Signed-off-by: Nicolas Iooss <nicolas.iooss_git@polytechnique.org>
fs_read_cgroup_files() grants access to reading files and to following
symlinks (with "read_lnk_files_pattern($1, cgroup_t, cgroup_t)").
fs_rw_cgroup_files() does not include such a rule, which is needed in
order to transparently use symlinks such as /sys/fs/cgroup/cpu. This
access is currently denied, for example to "systemd --user" daemon:
type=AVC msg=audit(1569756917.537:242): avc: denied { getattr }
for pid=9710 comm="systemd" path="/sys/fs/cgroup/cpu" dev="tmpfs"
ino=9683 scontext=sysadm_u:sysadm_r:sysadm_systemd_t
tcontext=system_u:object_r:cgroup_t tclass=lnk_file permissive=0
type=SYSCALL msg=audit(1569756917.537:242): arch=c000003e
syscall=262 success=no exit=-13 a0=ffffff9c a1=7ffc605b1f70
a2=7ffc605b1ea0 a3=100 items=0 ppid=1 pid=9710 auid=1000 uid=1000
gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000
fsgid=1000 tty=(none) ses=10 comm="systemd"
exe="/usr/lib/systemd/systemd"
subj=sysadm_u:sysadm_r:sysadm_systemd_t key=(null)
type=PROCTITLE msg=audit(1569756917.537:242):
proctitle=2F6C69622F73797374656D642F73797374656D64002D2D75736572
On this system (Debian 10), /sys/fs/cgroup/cpu is a symlink to
/sys/fs/cgroup/cpu,cpuacct.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
In order to detect bugs like the one fixed by commit d938683bf4
("drbd: fix pattern for /usr/lib/ocf/resource.d/linbit/drbd"), forbid
the use of \d in the policy. This was actually only used to match
/usr/share/apr-1/build/...
with
/usr/share/apr(-\d)?/build/[^/]+\.sh -- gen_context(system_u:object_r:bin_t,s0)
/usr/share/apr(-\d)?/build/libtool -- gen_context(system_u:object_r:bin_t,s0)
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Debian's PAM configuration uses a patched pam_motd module that runs
files in /etc/update-motd.d/ in order to generate a dynamic Message Of
The Day (MOTD). By default, there is only one script:
$ cat /etc/update-motd.d/10-uname
#!/bin/sh
uname -snrvm
According to https://wiki.debian.org/motd, the script is executed
through run-parts:
if (!system("/usr/bin/env -i
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
run-parts --lsbsysinit /etc/update-motd.d >
/run/motd.dynamic.new"))
rename("/run/motd.dynamic.new", "/run/motd.dynamic");
This requires allowing pam_motd users to execute bin_t commands
(/usr/bin/env) and shells (/bin/sh), and to manage /run/motd.dynamic*
files.
Allow relevant accesses for Debian-based systems.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
The pattern "(.*)?" means "match anything including the nothing, or
nothing": the question mark is redundant. This is likely to be a
mispelling for "(/.*)?", which means "match a slash and anthing, or
nothing", or for ".*", or for other patterns.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
In a pattern, a dot can match any character, including slash. It makes
sense when it is combined with ?, + or *, but makes little sense when
left alone.
Most of the time, the label was for file containing dots, where the dot
was not escaped. A few times, the dot was really intended to match any
character. In such case, [^/] better suits the intent.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
The pattern that matches /usr/include uses a dot, in order probably to
avoid calling m4's function include(). This also matches other paths
such as /usr/inclu/e. Such a side-effect can be avoided by inserting an
empty string which is removed by m4's preprocessing.
Mailing-list discussion: https://lore.kernel.org/selinux-refpolicy/CAJfZ7=krh_TaCBQzFxLM394Sc5-82ZO0DdcfvWON-RXu-wqBVw@mail.gmail.com/t/#u
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
