runcon: invalid context
by Tracy Reed
I want to manually run an app within a certain context. When I try running it
like so I get the following error:
# id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
# runcon p16001_u:myapp_r:myapp_t:s0:c1 /myapp/startup.sh
runcon: invalid context: p16001_u:myapp_r:myapp_t:s0:c1: Invalid argument
unconfined should be allowed to transition to any context, right? No AVC is
generated so I don't think that's the issue. The user p16001_u exists with
category c1, with role myapp_r and myapp_t exists in the policy. I'm unclear as
to why this is an invalid context.
# semanage user -l
Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range SELinux Roles
git_shell_u user s0 s0 git_shell_r
myapp_u user s0 s0-s0:c0.c1023 myapp_r
guest_u user s0 s0 guest_r
p16000_u user s0 s0-s0:c0 myapp_r
p16001_u user s0 s0-s0:c1 myapp_r
p16002_u user s0 s0-s0:c2 myapp_r
p16003_u user s0 s0-s0:c3 myapp_r
p16004_u user s0 s0-s0:c4 myapp_r
p16005_u user s0 s0-s0:c5 myapp_r
p16006_u user s0 s0-s0:c6 myapp_r
p16007_u user s0 s0-s0:c7 myapp_r
p16008_u user s0 s0-s0:c8 myapp_r
p16009_u user s0 s0-s0:c9 myapp_r
p16010_u user s0 s0-s0:c10 myapp_r
root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
sysadm_u user s0 s0-s0:c0.c1023 sysadm_r
system_u user s0 s0-s0:c0.c1023 system_r unconfined_r
unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r
user_u user s0 s0 user_r
xguest_u user s0 s0 xguest_r
Any tips greatly appreciated!
--
Tracy Reed
8 years, 5 months
Requesting feedback on providing containment of sslh
by James Hogarth
Hi,
I'm the maintainer of sslh and looking to get some feedback on a
policy I'm writing for it.
It has recently been added to the fedora repositories running
unconfined and I'm looking to improve this with running it within its
own confined domain.
The 'default' state is to listen on tcp/443 and to be able to connect
to tcp/80, tcp/443, tcp/5222, tcp/1194 (on both localhost and
arbitrary systems) which the default policy is configured for with the
option via booleans to let it listen on or connect to any port.
I've tried to style this after the services in fedora-selinux on
github in an attempt to make it consistent with existing policies.
I'd be grateful for any feedback on these before requesting this to be
added to the fedora targeted policy.
Kind regards,
James
sslh te file:
policy_module(sslh,1.0.0)
########################################
#
# Declarations
#
## <desc>
## <p>
## Determine whether sslh can connect
## to any tcp port or if it is restricted
## to the standard http, openvpn and jabber ports.
## </p>
## </desc>
gen_tunable(sslh_can_connect_any_port, false)
## <desc>
## <p>
## Determine whether sslh can listen
## on any tcp port or if it is restricted
## to the standard http.
## </p>
## </desc>
gen_tunable(sslh_can_bind_any_port, false)
type sslh_t;
type sslh_exec_t;
init_daemon_domain(sslh_t, sslh_exec_t)
type sslh_config_t;
files_config_file(sslh_config_t)
type sslh_initrc_exec_t;
init_script_file(sslh_initrc_exec_t)
type sslh_var_run_t;
files_pid_file(sslh_var_run_t)
type sslh_unit_file_t;
systemd_unit_file(sslh_unit_file_t)
########################################
#
# sslh local policy
#
allow sslh_t sslh_config_t:file read_file_perms;
auth_read_passwd(sslh_t)
allow sslh_t self:capability { setuid setgid };
allow sslh_t self:process { setcap getcap };
allow sslh_t self:tcp_socket create_stream_socket_perms;
sysnet_dns_name_resolve(sslh_t)
corenet_all_recvfrom_unlabeled(sslh_t)
corenet_all_recvfrom_netlabel(sslh_t)
corenet_tcp_sendrecv_generic_if(sslh_t)
corenet_udp_sendrecv_generic_if(sslh_t)
corenet_tcp_sendrecv_generic_node(sslh_t)
corenet_udp_sendrecv_generic_node(sslh_t)
corenet_tcp_bind_generic_node(sslh_t)
corenet_udp_bind_generic_node(sslh_t)
corenet_tcp_bind_http_port(sslh_t)
corenet_tcp_sendrecv_http_port(sslh_t)
corenet_tcp_connect_http_port(sslh_t)
corenet_tcp_connect_ssh_port(sslh_t)
corenet_tcp_sendrecv_ssh_port(sslh_t)
corenet_tcp_connect_openvpn_port(sslh_t)
corenet_tcp_sendrecv_openvpn_port(sslh_t)
corenet_tcp_connect_jabber_client_port(sslh_t)
corenet_tcp_sendrecv_jabber_client_port(sslh_t)
tunable_policy(`sslh_can_connect_any_port',`
# allow sslh to connect to any port
corenet_tcp_sendrecv_all_ports(sslh_t)
corenet_tcp_connect_all_ports(sslh_t)
')
tunable_policy(`sslh_can_bind_any_port',`
# allow sslh to bind to any port
corenet_tcp_sendrecv_all_ports(sslh_t)
corenet_tcp_bind_all_ports(sslh_t)
')
sslh fc file:
/usr/sbin/sslh -- gen_context(system_u:object_r:sslh_exec_t,s0)
/usr/sbin/sslh-select -- gen_context(system_u:object_r:sslh_exec_t,s0)
/etc/rc\.d/init\.d/sslh --
gen_context(system_u:object_r:sslh_initrc_exec_t,s0)
/etc/sslh.cfg -- gen_context(system_u:object_r:sslh_config_t,s0)
/usr/lib/systemd/system/sslh.* --
gen_context(system_u:object_r:sslh_unit_file_t,s0)
/usr/lib/systemd/system/sslh(a)*.* --
gen_context(system_u:object_r:sslh_unit_file_t,s0)
/var/run/sslh(/.*)? gen_context(system_u:object_r:sslh_var_run_t,s0)
8 years, 5 months
"invalid security context" in custom policy
by Tracy Reed
I am trying to confine a custom web application using type enforcement plus MCS
to protect multiple instances of the web app from each other. I can compile the
policy ok but when I insert it I get this error:
# semodule -i myapp.pp
libsepol.context_from_record: invalid security context: "myapp_u:myapp_r:myapp_api_t:s0"
libsepol.context_from_record: could not create context structure
libsepol.context_from_string: could not create context structure
libsepol.sepol_context_to_sid: could not convert myapp_u:myapp_r:myapp_api_t:s0 to sid
invalid context myapp_u:myapp_r:myapp_api_t:s0
libsemanage.semanage_install_active: setfiles returned error code 1.
semodule: Failed!
I'm sure I've seen this problem before but can't recall how it was fixed. I
know it's something fairly simple.
Here's myapp.te:
module myapp 1.0;
# Import some things we will need from other modules/default policy
require {
sensitivity s0;
category c0, c1, c2, c3, c4, c5, c6, c7, c8, c9, c10;
category c1023;
}
# Role and type for our app
role myapp_r;
type myapp_t;
# Glide file context
type myapp_bin_t;
type myapp_api_t;
type myapp_conf_t;
type myapp_release_t;
type myapp_incoming_t;
type myapp_lib_t;
type myapp_logs_t;
type myapp_scripts_t;
type myapp_tmp_t;
type myapp_tomcat_t;
type myapp_util_t;
type myapp_var_t;
type myapp_exec_t;
type myapp_webapps_t;
# Assign type attributes
corecmd_executable_file(myapp_bin_t)
corecmd_executable_file(myapp_exec_t)
#logging_log_file(myapp_logs_t)
# Generate one user per myapp instance with user and category matching the port
# it will bind to, only as convention, they don't technically have to match.
gen_user(myapp_u, myapp_t, myapp_r, s0, s0 - mls_systemhigh, c0.c1023)
gen_user(p16000_u, myapp_t, myapp_r, s0, s0 - mls_systemhigh, c0)
gen_user(p16001_u, myapp_t, myapp_r, s0, s0 - mls_systemhigh, c1)
gen_user(p16002_u, myapp_t, myapp_r, s0, s0 - mls_systemhigh, c2)
gen_user(p16003_u, myapp_t, myapp_r, s0, s0 - mls_systemhigh, c3)
gen_user(p16004_u, myapp_t, myapp_r, s0, s0 - mls_systemhigh, c4)
gen_user(p16005_u, myapp_t, myapp_r, s0, s0 - mls_systemhigh, c5)
gen_user(p16006_u, myapp_t, myapp_r, s0, s0 - mls_systemhigh, c6)
gen_user(p16007_u, myapp_t, myapp_r, s0, s0 - mls_systemhigh, c7)
gen_user(p16008_u, myapp_t, myapp_r, s0, s0 - mls_systemhigh, c8)
gen_user(p16009_u, myapp_t, myapp_r, s0, s0 - mls_systemhigh, c9)
gen_user(p16010_u, myapp_t, myapp_r, s0, s0 - mls_systemhigh, c10)
And while I'm posting I may as well ask: When I uncomment the
logging_log_file(mypp_logs_t) type attribute above I get this error:
Compiling targeted myapp module
/usr/bin/checkmodule: loading policy configuration from tmp/myapp.tmp
myapp.te":42:ERROR 'unknown class filesystem used in rule' at token ';' on line 1301:
allow myapp_logs_t tmp_t:filesystem associate;
#line 42
/usr/bin/checkmodule: error(s) encountered while parsing configuration
make: *** [tmp/myapp.mod] Error 1
All tips are greatly appreciated!
--
Tracy Reed
8 years, 5 months
tor_t: SELinux prevents tor from starting when using ControlSocket feature
by nusenu
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
if you make use of tor's ControlSocket feature, via config option
ControlSocket /var/lib/tor/foo/controlsocket
tor will fail to start with the following AVCs:
avc: denied { dac_override } for pid=7224 comm="tor" capability=1
scontext=system_u:system_r:tor_t:s0
tcontext=system_u:system_r:tor_t:s0 tclass=capability
avc: denied { dac_read_search } for pid=7224 comm="tor"
capability=2 scontext=system_u:system_r:tor_t:s0
tcontext=system_u:system_r:tor_t:s0 tclass=capability
avc: denied { dac_override } for pid=7226 comm="tor" capability=1
scontext=system_u:system_r:tor_t:s0
tcontext=system_u:system_r:tor_t:s0 tclass=capability
avc: denied { dac_read_search } for pid=7226 comm="tor"
capability=2 scontext=system_u:system_r:tor_t:s0
tcontext=system_u:system_r:tor_t:s0 tclass=capability
If you do not use the ControlSocket feature by removing that option
from the config file, tor starts up fine again.
Would be great if one could enable a boolean to allow that.
thanks!
Used policy:
selinux-policy-3.13.1-23.el7
selinux-policy-targeted-3.13.1-23.el7
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVJ9rAAAoJEFv7XvVCELh0/zYQAItBbT3uCuEclOz9kkPMxhR7
/R/yj08ynlB4L3Zs4xUmhQGAaS+E2As3ScfoViA3B2ywNcXF4A4l93GGV/fxe94H
GQp6v/cq7WVmHhJE5BdeBJ7ThJRuWpGGNjW+Pko/F/CCnAskLq4TKTDTHpgtwid6
r5LsN5Le6ypOO8Cp6jMpDAPgnz3JnTF2Yo3cRhPe/+DvDl5HFPHnr/bWeunKrzT0
Unn2n45IUeSTn50wPznAmAIQj00hLoQJCtv1TeprVy3FsJjzRrUUwxkIYJsVr5Cf
EF7ZFMZkpAqHKT5TQRdHYZ18CjOZS/waPY/XI8+RoL7cqXBU95/UcRt3gjcY3O3W
mI42IsQqM9SzV3vr98qWTN7V3GfNUg1BlAYVqWGXG3jRBvyACoZVg2nI0nyUSXG2
k2U9YuOF4zbBvlAD//tHhzTmfisuSMNE6lVW9osIW09HPpiX3htF0yZ+8I1VfZle
xM/NNwui6HRK28tTgqHXQpLlpBckO+db5S4mjojvbuHrv9H1tU5E1oK3YYwoEzUT
U+yh9I34o5N5he8kEIFHFMufEMkfzBBNb4MhotATTKhvuPXeFWlqJ5F1kWYT6mL5
0abfKB2xsQq7jZKIQSmcatLat6c98S90ipLEPS6aBWNeDCObYgSwaQcOZEFGQ+62
mMkave25Hgsy/BJ7e6SV
=eNqK
-----END PGP SIGNATURE-----
8 years, 5 months
Proper location for slapd kerberos ticket cache
by Jason L Tibbitts III
I'm running kerberized openldap, which means I need a kerberos keytab
and a ticket cache to provide to slapd. The locations of these files
are passed to slapd in environment variables and there's no Fedora
default for the file locations. (I guess there aren't too many people
running kerberized openldap.) This means I'm free to choose the
locations, but selinux gets upset if I choose the "wrong" ones.
The keytab is pretty much a fixed configuration file, and is fine to
live in /etc/openldap. The ticket cache, however, must be periodically
renewed by a cron job, and must be mode 600 owned by the ldap user. The
ldap user can't write to /etc/openldap, and I'd prefer not to allow it
to do so. /etc/openldap isn't really the right place anyway. The
"appropriate" place for this would generally be /var/cache/openldap, but
selinux won't let slapd read from there:
type=AVC msg=audit(1429645682.010:32711): avc: denied { getattr } for
pid=9186 comm="slapd" path="/var/cache/openldap/slapd.krb5cache"
dev="dm-1" ino=131308 scontext=system_u:system_r:slapd_t:s0
tcontext=unconfined_u:object_r:var_t:s0 tclass=file permissive=0
Now, I can obviously just run semanage and add an fcontext for that
location but if possible I'd like to pick something that doesn't require
me to do that for every deployment. Is there a location I can use for
this that's allowed by policy currently? Or can I get the default
policy modified to provide one?
Thanks,
- J<
8 years, 5 months
Running iotop as sysadm_r
by William
Hi,
I am trying to run iotop as sysadm_t
staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
This triggers a number of AVC's
I figured that perhaps sysadm_t isn't allowed access to the iotop
domain. So I had a look and found in sysadm.te where this should go,
such as:
optional_policy(`
iotop_run(sysadm_t, sysadm_r)
')
I'm getting a number of denials such as:
type=SYSCALL msg=audit(1429158621.683:1391): arch=c000003e syscall=41
success=yes exit=7 a0=10 a1=3 a2=10 a3=3 items=0 ppid=19850 pid=3617
auid=1176360 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts1 ses=1 comm="iotop" exe="/usr/bin/python2.7"
subj=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1429158621.684:1392): avc: denied { setopt } for
pid=3617 comm="iotop" scontext=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023
tcontext=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 tclass=netlink_socket
permissive=1
type=SYSCALL msg=audit(1429158621.684:1392): arch=c000003e syscall=54
success=yes exit=0 a0=7 a1=1 a2=7 a3=7fff1f3acb7c items=0 ppid=19850
pid=3617 auid=1176360 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=pts1 ses=1 comm="iotop" exe="/usr/bin/python2.7"
subj=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1429158621.684:1393): avc: denied { bind } for
pid=3617 comm="iotop" scontext=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023
tcontext=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 tclass=netlink_socket
permissive=1
type=SYSCALL msg=audit(1429158621.684:1393): arch=c000003e syscall=49
success=yes exit=0 a0=7 a1=7fff1f3ac9d0 a2=c a3=7fff1f3aca00 items=0
ppid=19850 pid=3617 auid=1176360 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="iotop"
exe="/usr/bin/python2.7" subj=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023
key=(null)
type=AVC msg=audit(1429158621.684:1394): avc: denied { getattr } for
pid=3617 comm="iotop" scontext=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023
tcontext=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 tclass=netlink_socket
permissive=1
type=SYSCALL msg=audit(1429158621.684:1394): arch=c000003e syscall=51
success=yes exit=0 a0=7 a1=7fff1f3ac9c0 a2=7fff1f3ac9bc a3=7fff1f3aca00
items=0 ppid=19850 pid=3617 auid=1176360 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="iotop"
exe="/usr/bin/python2.7" subj=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023
key=(null)
type=AVC msg=audit(1429158621.687:1395): avc: denied { write } for
pid=3617 comm="iotop" scontext=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023
tcontext=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 tclass=netlink_socket
permissive=1
type=SYSCALL msg=audit(1429158621.687:1395): arch=c000003e syscall=44
success=yes exit=36 a0=3 a1=7fae4ac392d4 a2=24 a3=0 items=0 ppid=19850
pid=3617 auid=1176360 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=pts1 ses=1 comm="iotop" exe="/usr/bin/python2.7"
subj=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1429158621.687:1396): avc: denied { read } for
pid=3617 comm="iotop" scontext=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023
tcontext=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 tclass=netlink_socket
permissive=1
type=SYSCALL msg=audit(1429158621.687:1396): arch=c000003e syscall=45
success=yes exit=112 a0=3 a1=1369764 a2=4000 a3=0 items=0 ppid=19850
pid=3617 auid=1176360 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=pts1 ses=1 comm="iotop" exe="/usr/bin/python2.7"
subj=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 key=(null)
^C
If we focus on one of them:
type=AVC msg=audit(1429158621.684:1394): avc: denied { getattr } for
pid=3617
comm="iotop"
scontext=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023
tcontext=staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023
tclass=netlink_socket
permissive=1
However, this should be allowed as:
sesearch -A -s iotop_t
allow iotop_t iotop_t : netlink_route_socket { ioctl read write
create getattr setattr lock append bind connect getopt setopt shutdown
nlmsg_read } ;
I think that i'm missing something related to the sysadm_r roles. What's
the correct way to edit the policy to allow sysadm_r to run iotop_t
correctly? Tips would be appreciated.
Sincerely,
--
William <william(a)firstyear.id.au>
8 years, 5 months
Strange requirement: confine unconfined
by W. Michael Petullo
I have a requirement which seems to be most easily satisfied by confining
unconfined users. Please let me explain:
Imagine some file "foo" that must remain secret. Now imagine a dynamic
system which must allow arbitrary (possibly untrustworthy, possibly
as-root, possibly user-installed) programs to run. Nothing matters except
keeping "foo" secret.
Is it possible to construct an SELinux policy which would satisfy such
a requirement?
For example, it would be helpful to allow users to run their programs
unconfined (to allow user-installed, policyless, etc. programs) yet still
enforce the policy as it pertains to "foo". Of course, it further seems
that SELinux would also have to ensure certain other restrictions apply
to unconfined users, such as running semodule or insmod.
Alternatively, would it be possible to construct a not-quite-unconfined
user by granting all syscalls on all objects *except* those labeled
"foo_t" (and semodule, etc.)?
I have worked with custom policies before both for software I have written
and for standard software, but this seems a bit different. It may be that
I have my model wrong, so I would appreciate any guidance whether along
the implementation lines I suggested or not (but holding to the original
requirements). It is also possible that I have overlooked some existing
literature.
Thank you!
--
Mike
:wq
8 years, 5 months
tor_t: actually allowed tcp ports
by nusenu
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
what are the actually allowed TCP ports processes in the tor_t domain
are allowed to bind to? (with tor_bind_all_unreserved_ports --> off
tor_can_network_relay --> on)
semanage gives me:
tor_port_t tcp 6969, 9001, 9030, 9050, 9051, 9150
but tor can bind to 80,443 or 9000 without problems.
(but for example 5000 is not allowed -> AVCs)
Used policy version:
selinux-policy-targeted-3.13.1-23.el7.noarch
Is there already a boolean that allows enabling to arbitrary ports
as suggested here:
https://bugzilla.redhat.com/show_bug.cgi?id=544546#c5
thanks,
Nusenu
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVItGQAAoJEFv7XvVCELh0vugQAIJQHPPzgD7bOlWHaDVTL+LU
+sjOPKhy23+9sbizeJ0oURpS7Xfhy/YZIqvLmoP/7omWlwtsA5y9dRmIBO4Z8xVo
LPM5c7uhXSUdrsBUBgoHv7aBGvGoZ6c+CZbvQZ5gQIgTJjKsbsXB0XAU0Op7G/65
VzZYkAoHhljBs3U42C02Ln7nSMMKOHn+8htM3VmfEZZfYCTU3rCfo05Xi5de2RN7
9k3I28ChFRNHFfcu17CVQvtDBg00OJqLDqA5qKxDk1b7Q2ubR8ZI76QmFpL0fVZS
PVzRjnLo2GyDIjJwDjmMNe1oPbTGCCHvb4UCLPtAzwquzxhr1L+i3FS2OGGwhF+D
v3YrzYgiERjLI9zixTaM7QfNJ4nzPee8MMUpv6qlWYVh59zcI+hOSRCZA8u+m91E
rwm7XNzVNPAi8w886yPSsysgtpfj0ZNFPQWbc2EDBqo2Q27HOG2P9awb/K02lT5C
L6Ypqe4+9Mh9guzKiggfZDuXm/MDCWQMYUd/1JktpWikeRW9Ig0BQkOYevoLdM1o
ncDb4tyvk4X8S4ZxTo4187VJSRS5rq/1Py7GP0CzZ5DZQlm0K/93mJ7jqXWmRV5q
xjZ/tUycRuSiNH0PX+P3xF4aKB8+9NgBYLC+Rzv33JKTe2ayYSZorBJpBAxH887U
oEyxlu6VHTt8gqKpdBAM
=znLy
-----END PGP SIGNATURE-----
8 years, 5 months
Unexpected behavior in permissive mode
by Joseph L. Casale
With the policy updates that came with centos 7.1 update, I am trying to
update a few local policies we have but with `setenforce 0` I do not get
an avc at all when running my app, however enabling it and rerunning it
generates one, but without seeing them all that approach would be like
wack-a-mole.
The avc I am getting after setenforce 1 is run is:
type=AVC msg=audit(1428109185.330:570): avc: denied { execute_no_trans } for pid=3953 comm="su" path="/usr/sbin/unix_chkpwd" dev="dm-0" ino=25468477 scontext=system_u:system_r:bacula_t:s0 tcontext=sytype=SYSCAL
Why does this not trigger a denial in permissive mode?
Thanks,
jlc
8 years, 5 months
Change process domain upon reading a file
by W. Michael Petullo
Is it possible to cause a process to transition to a new domain but only
if it reads a file with a certain label? I am interested in imposing
this by modifying the SELinux policy only, that is, not requiring any
action on the part of the process itself. You could think of this as a
rough analog to HiStar and others' "tainting".
--
Mike
:wq
8 years, 5 months
