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
