In the last article
https://linux-blog.anracom.com/2016/08/16/open-visual-traceroute-opensuse-leap-42-1-and-sudo-howto-i/
of this series I discussed basic steps to get OVT running on an Opensuse Leap 42.1 system. All recipes were based on assigning root rights to the Java-execution of the application’s jar. Root rights were required to perform network packet capturing.
Now, on a multiuser system
- we want to restrict the access rights to OVT to a group of selected users,
- we want to improve the startup – such that the selected users do not need to provide the root password.
Note that none of the steps below solves any security problems. It only makes things more convenient.
Change access rights to the OVT files
As in the first article we assume that the OVT-files were placed in a directory “/PATH/TO/OVT” – e.g. “/opt/ovt”.
- Step 1 – Create a group “ovt” : We create a user group named “ovt” (e.g. with “yast2” or at the commandline with “groupadd”). Then we add the users who later on shall get the privilege to execute “ovtr.sh” – even without giving the root password!
- Step 2 – Change ownership of “/PATH/TO/OVT” and its subdirectories/files:
chown -R root.ovt /PATH/TO/OVT - Step 3 – Change access rights to “/PATH/TO/OVT” and subdirectories/files:
chmod -R u+rwx,g+rx-w,o-rwx /PATH/TO/OVT
Changes to /etc/sudoers
We change the file “/etc/sudoers” by using the “visudo” command. (Do NOT edit the “/etc/sudoers”-file directly with an editor – get acquainted with elementary vi-commands if necessary!) I only show options which have an impact on the execution of the “ovtr.sh” file, which starts the OVT Java-program. I do not care about other settings and restrictions in comparison to the standard /etc/sudoers file Opensuse delivers.
- Step 4 – Add a “Default” definition to the sudoers file:
Below the last line of existing DEFAULT-definitions in the standard “/etc/sudoers”-file of Opensuse add a line
Defaults!/PATH/TO/OVT/ovtr.sh env_keep += “DISPLAY XAUTHORIZATION XAUTHORITY”
(With the double quotation marks! And, of course, you have to replace /PATH/TO/OVT by the path where you actually installed OVT.) This settings will later allow to keep up the named environment variables (DISPLAY, XAUTHORITY, …) when the command “ovtr.sh” is executed. - Step 5 – Add a group related definition to the sudoers file:
Add a line at the end of your settings for users and groups saying
%ovt ALL = (root) NOPASSWD: /PATH/TO/OVT/ovtr.sh
The last rule guarantees that all members of the group “ovt” can execute
sudo /PATH/TO/OVT/ovtr.sh
without providing the root passsword (or their own password depending on whether Opensuse’s default setting “Defaults targetpw” is kept up in your “sudoers”-file). The first rule preserves the present environment settings of user (member of group “ovt”) regarding DISPLAY and XAUTHORITY, thus enabling the access to the presently open X11-screen.
Simplify the contents of “ovtr.sh”
After the changes described above we only need a small modification to ovtr.sh:
#!/bin/bash java -Djava.awt.headless=false -Xmx512m -jar org.leo. traceroute.jar
This is now all that is required!
Let us test it
me@mytux:/opt/ovt> sudo ./ovtr.sh 12:43:54.768 [main] INFO org.leo.traceroute.Main - Open Visual Traceroute 1.6.3 12:43:54.776 [main] INFO org.leo.traceroute.install.Env - Java run-time version: 1.8.0_101 12:43:54.777 [main] INFO org.leo.traceroute.install.Env - NASA World Wind Java 2.0 2.0.0 12:43:54.777 [main] INFO org.leo.traceroute.install.Env - /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib 12:43:54.777 [main] INFO org.leo.traceroute.install.Env - OS:Linux / arch:amd64 Locale en_GB 12:43:57.230 [SwingWorker-pool-1-thread-1] INFO o.leo.traceroute.core.geo.GeoService - Use geoip db /root/ovtr/GeoLiteCity.dat which is 0 day(s) old 12:43:58.818 [pool-2-thread-1] INFO o.leo.traceroute.core.ServiceFactory - Try using device eth0 null 12:43:59.056 [pool-2-thread-2] INFO o.leo.traceroute.core.ServiceFactory - Try using device br0 null 12:43:59.251 [pool-2-thread-3] INFO o.leo.traceroute.core.ServiceFactory - Try using device virbr_vmw null 12:44:00.389 [pool-2-thread-8] INFO o.leo.traceroute.core.ServiceFactory - Try using device vmnet1 null 12:44:01.488 [pool-2-thread-9] INFO o.leo.traceroute.core.ServiceFactory - Try using device virbr1 null 12:44:02.589 [pool-2-thread-10] INFO o.leo.traceroute.core.ServiceFactory - Try using device virbr2 null 12:44:03.691 [pool-2-thread-11] INFO o.leo.traceroute.core.ServiceFactory - Try using device vmnet3 null 12:44:04.799 [pool-2-thread-12] INFO o.leo.traceroute.core.ServiceFactory - Try using device virbr3 null 12:44:05.908 [pool-2-thread-13] INFO o.leo.traceroute.core.ServiceFactory - Try using device virbr4 null 12:44:07.027 [pool-2-thread-14] INFO o.leo.traceroute.core.ServiceFactory - Try using device virbr5 null 12:44:08.124 [pool-2-thread-15] INFO o.leo.traceroute.core.ServiceFactory - Try using device virbr6 null 12:44:09.231 [pool-2-thread-17] INFO o.leo.traceroute.core.ServiceFactory - Try using device lo null 12:44:11.467 [AWT-EventQueue-0] INFO org.leo.traceroute.Main - Startup completed in 16704ms
Great !
Final convenience steps
We eventually add the path of our OVT installation to the system path variable or tell the users of group “ovt” to add it to their environment.
Another way for a user to simplify the OVT startup would be to put a small script “ovsh” in his home directory with just the lines :
#!/bin/bash
sudo /opt/ovt/ovtr.sh
Then he/she may start OVT by executing “ovsh”. The only difference is that we do not need to type the “sudo”.
Security?
In this article we have made the startup of OVT more convenient by using the /etc/sudoers” file. We also restricted access to OVT to members of a group. Still: Java is executed with root rights. This is something I, personally, do not like because of security reasons. The next article, therefore, concentrates on the possibility to start OVT in a chroot jail.