selinux April 2015

selinux@lists.fedoraproject.org

13 participants
12 discussions

runcon: invalid context
by Tracy Reed 06 May '15

06 May '15

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

2 3

Requesting feedback on providing containment of sslh
by James Hogarth 01 May '15

01 May '15

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)

3 3

"invalid security context" in custom policy
by Tracy Reed 29 Apr '15

29 Apr '15

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

3 3

tor_t: SELinux prevents tor from starting when using ControlSocket feature
by nusenu 24 Apr '15

24 Apr '15

-----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-----

2 4

Proper location for slapd kerberos ticket cache
by Jason L Tibbitts III 24 Apr '15

24 Apr '15

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<

3 2

Running iotop as sysadm_r
by William 20 Apr '15

20 Apr '15

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>

2 3

Strange requirement: confine unconfined
by W. Michael Petullo 14 Apr '15

14 Apr '15

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

2 1

tor_t: actually allowed tcp ports
by nusenu 14 Apr '15

14 Apr '15

-----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-----

3 5

Unexpected behavior in permissive mode
by Joseph L. Casale 12 Apr '15

12 Apr '15

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

2 6

Change process domain upon reading a file
by W. Michael Petullo 09 Apr '15

09 Apr '15

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

4 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux April 2015