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;
# 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;
# 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;
# 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!
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.fedoraproject
.org
_______________________________________________
selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
