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(a)lists.fedoraproject.org
>>> To unsubscribe send an email to selinux-leave(a)lists.fedoraproject
>>> .org