On Mon, 2017-05-29 at 12:43 -0700, Bill Durant wrote:
> Hello Stephen:
>
> I went ahead and tried to just declare green_jar_t and made it a
> file
> type as you have suggested but I think I may have something wrong
> with
> the TE policy that I created. Here is what I did and the error that
> I
> am getting:
>
> # uname -a
> Linux es300h 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Apr 11 17:13:24
> UTC
> 2017 x86_64 x86_64 x86_64 GNU/Linux
>
> # cat /etc/redhat-release
> CentOS release 6.9 (Final)
>
> # whoami
> root
>
> # setenforce 0
>
> # cp /etc/selinux/targeted/contexts/users/user_u
> /etc/selinux/targeted/contexts/users/red_u
> # cp /etc/selinux/targeted/contexts/users/user_u
> /etc/selinux/targeted/contexts/users/green_u
> # sed -i 's/user/red/g' /etc/selinux/targeted/contexts/users/red_u
> # sed -i 's/user/green/g'
> /etc/selinux/targeted/contexts/users/green_u
>
> # cd red
>
> # cat red_user.te
> policy_module(red, 0.0.1)
> role red_r;
> userdom_unpriv_user_template(red)
> gen_user(red_u, user, red_r, s0, s0)
>
> # cat red_app.te
> policy_module(red_app, 0.0.1)
> type red_jar_t;
> files_type(red_jar_t)
> role red_r types red_jar_t;
You don't need the above role statement, because red_jar_t is only used
as a file type (with object_r), never as a process type/domain.
>
> # cat red_app.fc
> /usr/local/soup/bin/red.jar --
> gen_context(system_u:object_r:red_jar_t, s0)
>
> # make -f /usr/share/selinux/devel/Makefile
> Compiling targeted red_app module
> /usr/bin/checkmodule: loading policy configuration from
> tmp/red_app.tmp
> /usr/bin/checkmodule: policy configuration loaded
> /usr/bin/checkmodule: writing binary representation (version 10) to
> tmp/red_app.mod
> Creating targeted red_app.pp policy package
> Compiling targeted red_user module
> /usr/bin/checkmodule: loading policy configuration from
> tmp/red_user.tmp
> /usr/bin/checkmodule: policy configuration loaded
> /usr/bin/checkmodule: writing binary representation (version 10) to
> tmp/red_user.mod
> Creating targeted red_user.pp policy package
> rm tmp/red_user.mod tmp/red_user.mod.fc tmp/red_app.mod
> tmp/red_app.mod.fc
>
> # semodule -i red_user.pp red_app.pp
>
> # restorecon -v /usr/local/soup/bin/red.jar
> restorecon reset /usr/local/soup/bin/red.jar context
> system_u:object_r:bin_t:s0->system_u:object_r:red_jar_t:s0
>
> # ls -Z /usr/local/soup/bin/red.jar
> -rwxr-xr-x. root root system_u:object_r:red_jar_t:s0
> /usr/local/soup/bin/red.jar
>
> # cd ../green
>
> # cat green_user.te
> policy_module(green, 0.0.1)
> role green_r;
> userdom_unpriv_user_template(green)
> gen_user(green_u, user, green_r, s0, s0)
>
> # cat green_app.te
> policy_module(green_app, 0.0.1)
> type green_jar_t;
> files_type(green_jar_t)
> role green_r types green_jar_t;
Likewise for the above role statement.
>
> # cat green_app.fc
> /usr/local/soup/bin/green.jar --
> gen_context(system_u:object_r:green_jar_t, s0)
>
> # make -f /usr/share/selinux/devel/Makefile
> Compiling targeted green_app module
> /usr/bin/checkmodule: loading policy configuration from
> tmp/green_app.tmp
> /usr/bin/checkmodule: policy configuration loaded
> /usr/bin/checkmodule: writing binary representation (version 10) to
> tmp/green_app.mod
> Creating targeted green_app.pp policy package
> Compiling targeted green_user module
> /usr/bin/checkmodule: loading policy configuration from
> tmp/green_user.tmp
> /usr/bin/checkmodule: policy configuration loaded
> /usr/bin/checkmodule: writing binary representation (version 10) to
> tmp/green_user.mod
> Creating targeted green_user.pp policy package
> rm tmp/green_user.mod.fc tmp/green_app.mod tmp/green_user.mod
> tmp/green_app.mod.fc
>
> # semodule -i green_user.pp green_app.pp
>
> # restorecon -v /usr/local/soup/bin/green.jar
> restorecon reset /usr/local/soup/bin/green.jar context
> system_u:object_r:bin_t:s0->system_u:object_r:green_jar_t:s0
>
> # ls -Z /usr/local/soup/bin/green.jar
> -rwxr-xr-x. root root system_u:object_r:green_jar_t:s0
> /usr/local/soup/bin/green.jar
>
> # useradd -Z green_u mary
>
> # useradd -Z red_u jack
>
> # passwd mary
> Changing password for user mary.
> New password:
> Retype new password:
> passwd: all authentication tokens updated successfully.
>
> # passwd jack
> Changing password for user jack.
> New password:
> Retype new password:
> passwd: all authentication tokens updated successfully.
>
> # setenforce 1
>
> Now login as Linux user mary and notice that java is unable to read
> the
> JAR file which is NOT expected:
>
> $ whoami
> mary
>
> $ java -jar /usr/local/soup/bin/green.jar
> Error: Unable to access jarfile /usr/local/soup/bin/green.jar
>
> Now let's try to fix that with audit2allow:
>
> From /var/log/audit/audit.log:
> ...
> ...
> type=AVC msg=audit(1496085668.816:22282): avc: denied { read }
> for
> pid=10657 comm="java" name="green.jar" dev=dm-0 ino=934010
> scontext=green_u:green_r:green_java_t:s0
> tcontext=system_u:object_r:green_jar_t:s0 tclass=file
>
> ...
> ...
>
> # grep java /var/log/audit/audit.log | audit2allow -m java > foo.te
>
> # cat foo.te
>
> module java 1.0;
>
> require {
> type user_tmp_t;
> type green_java_t;
> type vmblock_t;
> type sshd_t;
> type sysctl_fs_t;
> type usr_t;
> type green_jar_t;
> class dir { getattr search };
> class file { read execute append };
> }
>
> #============= green_java_t ==============
> allow green_java_t green_jar_t:file read;
>
> #============= sshd_t ==============
> allow sshd_t sysctl_fs_t:dir search;
> allow sshd_t user_tmp_t:file execute;
> allow sshd_t usr_t:file append;
> allow sshd_t vmblock_t:dir getattr;
There are several problems with this policy module:
1) You named it "java", and therefore it will replace the refpolicy
java policy module when you try to install it (that's why you get the
error below, because you are removing the java module definitions when
you insert this one).
2) You included several unrelated requires and allow rules above that
have nothing to do with this denial. You want to be more selective in
what you select with ausearch or remove the extraneous ones afterward.
3) You will need more than just read permission ultimately (e.g. open,
possibly others). Better to use a refpolicy macro instead.
So, for example, I would write this as:
policy_module(greenjava, 1.0)
require {
type green_java_t;
type green_jar_t;
}
allow green_java_t green_jar_t:file read_file_perms;
And probably I would just insert the above requires and allow rules
into your already existing green_app.te module instead of creating a
separate one.
>
> # make -f /usr/share/selinux/devel/Makefile
> Compiling targeted foo module
> /usr/bin/checkmodule: loading policy configuration from tmp/foo.tmp
> /usr/bin/checkmodule: policy configuration loaded
> /usr/bin/checkmodule: writing binary representation (version 10) to
> tmp/foo.mod
> Creating targeted foo.pp policy package
> rm tmp/foo.mod.fc tmp/foo.mod
>
> # semodule -i foo.pp
> libsepol.print_missing_requirements: java's global requirements were
> not
> met: type/attribute green_java_t (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file
> or
> directory).
> semodule: Failed!
Again, this is because you named your module java and therefore it is
viewed as a replacement for the refpolicy java module, and thereby
removing the normal java policy definitions.
> You have new mail in /var/spool/mail/root
>
> # sesearch -A -s green_java_t -t green_jar_t -c file
> Found 1 semantic av rules:
> allow green_java_t file_type : file execmod ;
>
> What am I missing?
>
> Thank you & Best Regards,
>
> Bill
>
> P.S. I have subscribed to the refpolicy mailing list but I am still
> waiting for my subscription request to get accepted.
>
> On 05/26/2017 06:58 AM, Stephen Smalley wrote:
> > On Thu, 2017-05-25 at 14:20 -0700, Bill D wrote:
> > > Hello Stephen:
> > >
> > > I tried it via RBAC/TE without success.
> > >
> > > How to prevent a Linux user from reading/running a Java JAR file
> > > via
> > > RBAC/TE?
> > >
> > > Here is what I did:
> > >
> > > # id -u
> > > 0
> > >
> > > # uname -a
> > > Linux rhel-billd 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21
> > > 12:19:18
> > > EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
> > >
> > > # cat /etc/redhat-release
> > > Red Hat Enterprise Linux Server release 6.9 (Santiago)
> > >
> > > # setenforce 0
> > >
> > > # getenforce
> > > Permissive
> > >
> > > # cd green
> > >
> > > # cat green_app.te
> > > policy_module(green_app, 0.0.1)
> > > type green_app_t;
> > > type green_app_exec_t;
> > > application_executable_file(green_app_exec_t)
> > > application_domain(green_app_t, green_app_exec_t)
> > > role green_r types green_app_t;
> > > require { type green_t; }
> > > domain_auto_trans(green_t, green_app_exec_t, green_app_t)
> >
> > Note that most of this policy module is unnecessary/unused, because
> > you
> > aren't truly executing the jar files, so there is no domain
> > transition,
> > and hence neither green_app_t nor the rules generated by
> > application_domain() or domain_auto_trans() are ever
> > exercised. The
> > definitions you have above are more suitable to an executable
> > program,
> > not a data file, and at the end of the day, a .jar file is really
> > just
> > data. I would just declare green_jar_t and make it a file_type()
> > only.
> >
> > > # cat green_user.te
> > > policy_module(green, 0.0.1)
> > > role green_r;
> > > userdom_unpriv_user_template(green)
> > > gen_user(green_u, user, green_r, s0, s0)
> > >
> > > # cat green_app.fc
> > > /usr/local/soup/bin/green.jar --
> > > gen_context(system_u:object_r:green_app_exec_t, s0)
> > >
> > > # cp /etc/selinux/targeted/contexts/users/user_u
> > > /etc/selinux/targeted/contexts/users/green_u
> > >
> > > # sed -i 's/user/green/g'
> > > /etc/selinux/targeted/contexts/users/green_u
> > >
> > > # cat /etc/selinux/targeted/contexts/users/green_u
> > > system_r:local_login_t:s0 green_r:green_t:s0
> > > system_r:remote_login_t:s0 green_r:green_t:s0
> > > system_r:sshd_t:s0 green_r:green_t:s0
> > > system_r:crond_t:s0 green_r:green_t:s0
> > > system_r:xdm_t:s0 green_r:green_t:s0
> > > green_r:green_su_t:s0 green_r:green_t:s0
> > > green_r:green_sudo_t:s0 green_r:green_t:s0
> > > system_r:initrc_su_t:s0 green_r:green_t:s0
> > > green_r:green_t:s0 green_r:green_t:s0
> > >
> > > # make -f /usr/share/selinux/devel/Makefile
> > > Compiling targeted green_app module
> > > /usr/bin/checkmodule: loading policy configuration from
> > > tmp/green_app.tmp
> > > /usr/bin/checkmodule: policy configuration loaded
> > > /usr/bin/checkmodule: writing binary representation (version 10)
> > > to
> > > tmp/green_app.mod
> > > Creating targeted green_app.pp policy package
> > > Compiling targeted green_user module
> > > /usr/bin/checkmodule: loading policy configuration from
> > > tmp/green_user.tmp
> > > /usr/bin/checkmodule: policy configuration loaded
> > > /usr/bin/checkmodule: writing binary representation (version 10)
> > > to
> > > tmp/green_user.mod
> > > Creating targeted green_user.pp policy package
> > > rm tmp/green_user.mod.fc tmp/green_app.mod tmp/green_user.mod
> > > tmp/green_app.mod.fc
> > >
> > > # cat green_app.if
> > > ## <summary></summary>
> > >
> > > # cat green_user.if
> > > ## <summary></summary>
> > >
> > > # cat green_user.fc
> > >
> > > # semodule -i green_user.pp green_app.pp
> > >
> > > # useradd -Z green_u mary
> > >
> > > # passwd mary
> > > Changing password for user mary.
> > > New password:
> > > Retype new password:
> > > passwd: all authentication tokens updated successfully.
> > >
> > > # restorecon -v /usr/local/soup/bin/green.jar
> > > restorecon reset /usr/local/soup/bin/green.jar context
> > > system_u:object_r:bin_t:s0->system_u:object_r:green_app_exec_t:s0
> > >
> > > # ls -Z /usr/local/soup/bin/green.jar
> > > -rwxr-xr-x. admin admin
> > > system_u:object_r:green_app_exec_t:SystemLow
> > > /usr/local/soup/bin/green.jar
> > >
> > > # cd ../red
> > >
> > > # cat red_app.te
> > > policy_module(red_app, 0.0.1)
> > > type red_app_t;
> > > type red_app_exec_t;
> > > application_executable_file(red_app_exec_t)
> > > application_domain(red_app_t, red_app_exec_t)
> > > role red_r types red_app_t;
> > > require { type red_t; }
> > > domain_auto_trans(red_t, red_app_exec_t, red_app_t)
> >
> > Same as for green_app.te above.
> >
> > > # cat red_user.te
> > > policy_module(red, 0.0.1)
> > > role red_r;
> > > userdom_unpriv_user_template(red)
> > > gen_user(red_u, user, red_r, s0, s0)
> > >
> > > # cat red_app.fc
> > > /usr/local/soup/bin/red.jar --
> > > gen_context(system_u:object_r:red_app_exec_t, s0)
> > >
> > > # cp /etc/selinux/targeted/contexts/users/user_u
> > > /etc/selinux/targeted/contexts/users/red_u
> > >
> > > # sed -i 's/user/red/g'
> > > /etc/selinux/targeted/contexts/users/red_u
> > >
> > > # cat /etc/selinux/targeted/contexts/users/red_u
> > > system_r:local_login_t:s0 red_r:red_t:s0
> > > system_r:remote_login_t:s0 red_r:red_t:s0
> > > system_r:sshd_t:s0 red_r:red_t:s0
> > > system_r:crond_t:s0 red_r:red_t:s0
> > > system_r:xdm_t:s0 red_r:red_t:s0
> > > red_r:red_su_t:s0 red_r:red_t:s0
> > > red_r:red_sudo_t:s0 red_r:red_t:s0
> > > system_r:initrc_su_t:s0 red_r:red_t:s0
> > > red_r:red_t:s0 red_r:red_t:s0
> > >
> > > # make -f /usr/share/selinux/devel/Makefile
> > > Compiling targeted red_app module
> > > /usr/bin/checkmodule: loading policy configuration from
> > > tmp/red_app.tmp
> > > /usr/bin/checkmodule: policy configuration loaded
> > > /usr/bin/checkmodule: writing binary representation (version 10)
> > > to
> > > tmp/red_app.mod
> > > Creating targeted red_app.pp policy package
> > > Compiling targeted red_user module
> > > /usr/bin/checkmodule: loading policy configuration from
> > > tmp/red_user.tmp
> > > /usr/bin/checkmodule: policy configuration loaded
> > > /usr/bin/checkmodule: writing binary representation (version 10)
> > > to
> > > tmp/red_user.mod
> > > Creating targeted red_user.pp policy package
> > > rm tmp/red_user.mod tmp/red_user.mod.fc tmp/red_app.mod
> > > tmp/red_app.mod.fc
> > >
> > > # cat red_app.if
> > > ## <summary></summary>
> > >
> > > # cat red_user.if
> > > ## <summary></summary>
> > >
> > > # cat red_user.fc
> > >
> > > # semodule -i red_user.pp red_app.pp
> > >
> > > # useradd -Z red_u jack
> > >
> > > # passwd jack
> > > Changing password for user jack.
> > > New password:
> > > Retype new password:
> > > passwd: all authentication tokens updated successfully.
> > >
> > > # restorecon -v /usr/local/soup/bin/red.jar
> > > restorecon reset /usr/local/soup/bin/red.jar context
> > > system_u:object_r:bin_t:s0->system_u:object_r:red_app_exec_t:s0
> > >
> > > # ls -Z /usr/local/soup/bin/red.jar
> > > -rwxr-xr-x. admin admin
> > > system_u:object_r:red_app_exec_t:SystemLow
> > > /usr/local/soup/bin/red.jar
> > >
> > > # setenforce 1
> > >
> > > # getenforce
> > > Enforcing
> > >
> > > Now logon as Linux user mary and notice that it can read/run
> > > red.jar
> > > which is NOT expected:
> > >
> > > $ whoami
> > > mary
> > >
> > > $ id -Z
> > > green_u:green_r:green_t:SystemLow
> > >
> > > $ ls -Z /usr/local/soup/bin/green.jar /usr/local/soup/bin/red.jar
> > > -rwxr-xr-x. admin admin
> > > system_u:object_r:green_app_exec_t:SystemLow
> > > /usr/local/soup/bin/green.jar
> > > -rwxr-xr-x. admin admin
> > > system_u:object_r:red_app_exec_t:SystemLow
> > > /usr/local/soup/bin/red.jar
> > >
> > > $ getenforce
> > > Enforcing
> > >
> > > $ java -jar /usr/local/soup/bin/green.jar
> > > Hello from the green application
> > >
> > > $ java -jar /usr/local/soup/bin/red.jar
> > > Hello from the red application
> >
> > So at this point you can query the policy to understand what is
> > allowing this access:
> > yum install setools-console
> > sesearch -A -s green_t -t red_app_exec_t -c file
> > Found 1 semantic av rules:
> > allow green_usertype application_exec_type : file { ioctl read
> > getattr lock execute execute_no_trans open } ;
> >
> > And if we look at the refpolicy headers, we see that all user
> > domains
> > are allowed to read/execute all applications:
> > # grep -n application_exec
> > /usr/share/selinux/devel/include/system/userdomain.if
> > 72: application_exec_all($1_usertype)
> >
> > So by declaring the types as application_executable_file(), you
> > allowed
> > all user domains to read/execute them. If you only make them
> > file_type(), then they won't be immediately readable/executable by
> > all
> > user domains.
> >
> > Depending on your goals, you may find that refpolicy's
> > userdom_unpriv_user_template() is too liberal in what it allows and
> > you
> > may want to define your own, more minimalist set.
> >
> > Questions/comments about refpolicy interfaces and implementation
> > should
> > go to the refpolicy mailing list,
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> >
> > > The same situation happens with user jack as follows:
> > >
> > > $ whoami
> > > jack
> > >
> > > $ id -Z
> > > red_u:red_r:red_t:SystemLow
> > >
> > > $ ls -Z /usr/local/soup/bin/green.jar /usr/local/soup/bin/red.jar
> > > -rwxr-xr-x. admin admin
> > > system_u:object_r:green_app_exec_t:SystemLow
> > > /usr/local/soup/bin/green.jar
> > > -rwxr-xr-x. admin admin
> > > system_u:object_r:red_app_exec_t:SystemLow
> > > /usr/local/soup/bin/red.jar
> > >
> > > $ getenforce
> > > Enforcing
> > >
> > > $ java -jar /usr/local/soup/bin/green.jar
> > > Hello from the green application
> > >
> > > $ java -jar /usr/local/soup/bin/red.jar
> > > Hello from the red application
> > >
> > > How to prevent mary from reading/running red.jar and jack from
> > > running/running green.jar?
> > >
> > > ===================================
> > >
> > > Following is how to create the JAR files:
> > >
> > > $ whoami
> > > admin
> > >
> > > $ id -Z
> > > unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh
> > >
> > > $ cat Green.java
> > > public class Green {
> > > public static void main(String[] args) {
> > > System.out.println("Hello from the green application");
> > > }
> > > }
> > >
> > > $ javac Green.java
> > >
> > > $ cat manifest.txt
> > > Main-Class:
> > >
> > > $ jar cvfe green.jar Green Green.class
> > > added manifest
> > > adding: Green.class(in = 436) (out= 301)(deflated 30%)
> > >
> > > $ ls -Z green.jar
> > > -rwxr-xr-x. admin admin
> > > system_u:object_r:green_app_exec_t:SystemLow
> > > green.jar
> > >
> > > $ cat Red.java
> > > public class Red {
> > > public static void main(String[] args) {
> > > System.out.println("Hello from the red application");
> > > }
> > > }
> > >
> > > $ javac Red.java
> > >
> > > $ cat manifest.txt
> > > Main-Class:
> > >
> > > $ jar cvfe red.jar Red Red.class
> > > added manifest
> > > adding: Red.class(in = 430) (out= 301)(deflated 30%)
> > >
> > > $ ls -Z red.jar
> > > -rwxr-xr-x. admin admin
> > > system_u:object_r:red_app_exec_t:SystemLow
> > > red.jar
> > >
> > > Best Regards,
> > >
> > > Bill
> > > On 05/24/2017 02:19 PM, Bill D wrote:
> > >
> > > > On 05/24/2017 01:36 PM, Stephen Smalley wrote:
> > > >
> > > > > On Tue, 2017-05-23 at 16:51 -0700, Bill D wrote:
> > > > > > Greetings:
> > > > > >
> > > > > > I have been trying to figure out how to control the
> > > > > > execution
> > > > > > of
> > > > > > Java
> > > > > > JAR files with SELinux RBAC.
> > > > > >
> > > > > > I have two Linux users named joe and mary and two Java JAR
> > > > > > files
> > > > > > named
> > > > > > jack.jar and mary.jar.
> > > > > >
> > > > > > Here is how jack executes jack.jar: java -jar jack.jar
> > > > > >
> > > > > > Here is how mary executes mary.jar: java -jar mary.jar
> > > > >
> > > > > So they aren't actually executing those files; they are both
> > > > > executing
> > > > > java, which in turn is reading those files and interpreting
> > > > > the
> > > > > contents.
> > > >
> > > > Correct.
> > > >
> > > >
> > > > > > I would like SELinux RBAC to prevent jack from executing
> > > > > > mary.jar
> > > > > > and
> > > > > > prevent mary from executing jack.jar.
> > > > > >
> > > > > > How to configure SELinux RBAC to make that happen?
> > > > > >
> > > > > > I have tried various approaches without success. I have
> > > > > > also
> > > > > > tried
> > > > > > the
> > > > > > steps in http://forums.fedoraforum.org/archive/index.php/t-
> > > > > > 2229
> > > > > > 38.htm
> > > > > > l
> > > > > > without success.
> > > > > >
> > > > > > I would greatly appreciate any hints.
> > > > >
> > > > > Perhaps you could describe what you tried in more detail, and
> > > > > how
> > > > > it
> > > > > failed. The thing to remember is that for your scenario
> > > > > above,
> > > > > you
> > > > > need to control read permission, not execute permission. You
> > > > > can
> > > > > either do this via RBAC/TE (in which case you need separate
> > > > > SELinux
> > > > > users, roles, and domains for jack and mary, and separate
> > > > > types
> > > > > for
> > > > > jack.jar and mary.jar), or via MCS/MLS (in which case you
> > > > > need to
> > > > > have
> > > > > jack and mary run in MCS constrained domains, authorize them
> > > > > for
> > > > > different categories, and assign those different categories
> > > > > to
> > > > > the .jar
> > > > > files).
> > > >
> > > > Thank you for making me realize that the access control that I
> > > > need
> > > > is
> > > > indeed read, not execute.
> > > >
> > > > I will try again via RBAC/TE and will provide details on what I
> > > > tried
> > > > if I still cannot get it to work.
> > > >
> > > > > Perhaps the better question is what is it that you are really
> > > > > trying to
> > > > > achieve. Merely controlling which jar files they can
> > > > > read/execute
> > > > > isn't terribly interesting; what prevents them from just re-
> > > > > creating or
> > > > > downloading the other .jar file themselves?
> > > >
> > > > I am trying to implement the least privilege concept on a
> > > > particular
> > > > system. At this point it is fine if the user copies the other
> > > > JAR
> > > > file to other systems since it will not run as expected on that
> > > > other
> > > > system. But this may become a requirement later...
> > > >
> > > > Thanks!
> > > >
> > > > Bill
> > > >
> > > > > _______________________________________________
> > > > > selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx
> > > > > To unsubscribe send an email to selinux-leave@lists.fedorapro
> > > > > ject
> > > > > .org
_______________________________________________
selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
