In many cases, this won't result in a change in the actual policy generated, but if the definitions of macros are changed going forward, the mismatches could cause issues.
Signed-off-by: Daniel Burgener <Daniel.Burgener@microsoft.com>
When using network namespaces with `ip netns`, command `ip` creates
files in `/run/netns` that are mountpoints for `nsfs`. For example:
$ ip netns add VPN
$ ls -Z /run/netns/VPN
system_u:object_r:nsfs_t /run/netns/VPN
$ findmnt /run/netns/VPN
TARGET SOURCE FSTYPE OPTIONS
/run/netns/VPN nsfs[net:[4026532371]] nsfs rw
/run/netns/VPN nsfs[net:[4026532371]] nsfs rw
From a shell CLI, it is possible to retrieve the name of the current
network namespace:
$ ip netns exec VPN bash
$ ip netns identify $$
VPN
This requires reading `/proc/$PID/ns/net`, which is labelled as a user
domain. Allow this access using `userdom_read_all_users_state()`.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
`sysdig` is a tool that enables introspecting the system, debugging it,
etc. It uses a driver that creates `/dev/sysdig0`. Define a specific
label in order to be able to allow using it.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
On Debian 10, ``systemd --user`` runs some generators in
/usr/lib/systemd/user-environment-generators when a user session starts.
Here is what is logged in audit.log for a sysadm user.
type=AVC msg=audit(1586962888.516:65): avc: denied { getattr } for
pid=309 comm="(sd-executor)"
path="/usr/lib/systemd/user-environment-generators/90gpg-agent"
dev="vda1" ino=662897 scontext=sysadm_u:sysadm_r:sysadm_systemd_t
tcontext=system_u:object_r:systemd_generator_exec_t tclass=file
permissive=1
type=AVC msg=audit(1586962888.516:66): avc: denied { map } for
pid=310 comm="30-systemd-envi"
path="/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator"
dev="vda1" ino=655822 scontext=sysadm_u:sysadm_r:sysadm_systemd_t
tcontext=system_u:object_r:systemd_generator_exec_t tclass=file
permissive=1
type=AVC msg=audit(1586962888.516:66): avc: denied
{ execute_no_trans } for pid=310 comm="(direxec)"
path="/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator"
dev="vda1" ino=655822 scontext=sysadm_u:sysadm_r:sysadm_systemd_t
tcontext=system_u:object_r:systemd_generator_exec_t tclass=file
permissive=1
Run these program without domain transition.
This follows a discussion that took place in
https://github.com/SELinuxProject/refpolicy/pull/224
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
During normal m4 parsing, m4 outputs a blank line for each define() call. This results in the first roughly 500 lines of the .tmp files for each module being largely blank lines. Adding divert() calls to the m4 generation for generated_definitions redirects this output, so the beginning of the actual policy appears near the top of the .tmp files.
Signed-off-by: Daniel Burgener <Daniel.Burgener@microsoft.com>
Don't ignore port ranges. For example:
network_port(amanda, udp,10080-10082,s0, tcp,10080-10083,s0)
can be used to generate:
base -A selinux_new_input -p udp --dport 10080:10082 -j SECMARK --selctx system_u:object_r:amanda_server_packet_t:s0
base -A selinux_new_input -p tcp --dport 10080:10083 -j SECMARK --selctx system_u:object_r:amanda_server_packet_t:s0
base -A selinux_new_output -p udp --dport 10080:10082 -j SECMARK --selctx system_u:object_r:amanda_client_packet_t:s0
base -A selinux_new_output -p tcp --dport 10080:10083 -j SECMARK --selctx system_u:object_r:amanda_client_packet_t:s0
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
Optionally generate Netfilter NFT tables. Sample output:
```#!/usr/sbin/nft -f
flush ruleset
table inet security {
secmark default_input_packet {
"system_u:object_r:server_packet_t:s0"
}
secmark default_output_packet {
"system_u:object_r:client_packet_t:s0"
}
secmark afs_bos_input {
"system_u:object_r:afs_bos_server_packet_t:s0"
}
secmark afs_bos_output {
"system_u:object_r:afs_bos_client_packet_t:s0"
}
...
chain INPUT {
type filter hook input priority 0; policy accept;
ct state new meta secmark set "default_input_packet"
ct state new udp dport 7007 meta secmark set "afs_bos_input"
...
ct state new ct secmark set meta secmark
ct state established,related meta secmark set ct secmark
}
chain FORWARD {
type filter hook forward priority 0; policy accept;
}
chain OUTPUT {
type filter hook output priority 0; policy accept;
ct state new meta secmark set "default_output_packet"
ct state new udp dport 7007 meta secmark set "afs_bos_output"
...
ct state new ct secmark set meta secmark
ct state established,related meta secmark set ct secmark
}
}
```
The labels are applied to TCP and/or UDP as needed. MCS and MLS are
not really handled.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
The various /bin/tpm2_* binaries use dbus to communicate
with tpm2-abrmd and also can directly access /dev/tpmrm0. This
seems like a way to help limit access to the TPM by running the
tpm_* binaries in their own domain.
I setup this domain because I have a process that needs to use
tpm2_hmac to encode something, but didn't want that domain to
have direct access to the TPM. I did some basic testing to verify
that the other tpm2_* binaries have basically the same access needs.
But it wasn't through testing of all the tpm2_* binaries.
Signed-off-by: Dave Sugar <dsugar@tresys.com>
When testing issues in older versions of refpolicy (for example when
git-bisecting a regression), the newer policy modules are kept in
/usr/share/selinux/refpolicy/ and trigger errors when they fail to be
loaded by "semodule -s refpolicy -i /usr/share/selinux/refpolicy/*.pp".
Avoid this situation by removed old modules from
/usr/share/selinux/refpolicy/ before running "make install".
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Use a separate directory for files generated my 'make conf', so the clean targets from Rules.* do not remove them.
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
Yes mmap is the standard way of accessing the mail spool.
Removed spamd_gpg_t because there's no point to it, the separation doesn't
provide an actual benefit.
Made the other requested changes.
Signed-off-by: Russell Coker <russell@coker.com.au>
Init, init scripts and udisks don't need to be able to create regular
files in /dev.
Thanks to Jarkko Sakkinen for the idea.
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>