You are not logged in.
Pages: 1
Hi,
I would like to sandbox a pair of applications (https://www.altair.com/compose/ and https://www.altair.com/activate/ ) which are freely available as a InstallAnywhere (tm) UNIX Self Extractor bash file compatible with Linux RHEL and CentOS 7.4 and SLES 12 SP3.
These applications use GUI and I would like to limit them to run and have write access only to the folder in which they are and its sub folders.
Is there a way to do that?
Should I use a chroot and in such a case how much space do I lose on my hdd?
Last edited by Xwang (2020-11-06 20:01:29)
Offline
I'd say your best option would be a container such as Docker - there may be docker containers already published. If it's gui heavy, that be problematic, but I think you can use the GPU with Docker. Otherwise use a virtual machine with CentOS is likely the quickest. Setting up CentOS on a VM isn't that time consuming. The other two distros require Red Hat licenses.
Offline
I have tried to install the application in a archlinux vm as user installing it in a folder without using sudo and it has worked correctly.
I presume that doing that the installation app can alter files only in the user home directory. Is it correct?
Is it possible to limit the installation app to write only to a sub folder of the user home or track what files are created/modified/deleted when the installation is executed?
Offline
Not really, the only thing I know of would be any of the containers systems already mentioned or something like/or apparmor...
Anything you run as a normal user and keeps the same privileges will be capable only of affecting your files, even if it was installed in the system it will be launched with your privileges and will only have access to files owned by your user (unless it’s a setuid something but that’s not the case)
Offline
So could firejail help me in achieving my aim?
Offline
If the app works fine when installing/running it as a regular user, you could just install and run it under a new (non root) user account as well, installed in that user's home folder. Then everything will be contained in that user's home folder.
Offline
If the app works fine when installing/running it as a regular user, you could just install and run it under a new (non root) user account as well, installed in that user's home folder. Then everything will be contained in that user's home folder.
You are right, but I would like to be logged as my user when running it, but maybe I can run it with kdesu -u (it is a graphical app). Is it correct?
Offline
I have not tried that myself, but the man page says you can:
-u user While the most common use for KDE su is to run a command as the superuser, you can supply any user name and the appropriate password.
Offline
I have not tried that myself, but the man page says you can:
man kdesu wrote:-u user While the most common use for KDE su is to run a command as the superuser, you can supply any user name and the appropriate password.
I've tried and kdesu -u user seems to work as expected (at least with glxgears).
The last question is what kind of user should I create.
For sure it need to have an home directory and I need to be able to login from the bash but not from GDM.
Any suggestion?
Offline
Well - the choice is yours, I don't think it matters. My personal choice would be to create a "normal" user called 'altair' in a default group called 'altair', etc. since the way you're using it is just like a regular user. Just expect that user to show up in GDM since its UID is greater than 1000.
Offline
What you are looking for is user privilege separation.
1, Assume you have two users, user1 is a privileged user, and user2 is not.
$ cat /etc/sudoers
user1 ALL= (ALL) NOPASSWD: ALL
2, From a Display Manager in Xorg, login as user1, open a urxvt and type
$ chmod go=x /home/user1
$ chmod go=r /home/user1/.Xauthority
$ exec su --pty --login user2
3, Now you are a child process of user1 but logged in as user2, then type
$ env -S DISPLAY=:0 XAUTHORITY=/home/user1/.Xauthority XDG_RUNTIME_DIR=seat1 setsid --fork urxvt
4, Now you are a detached process from user1
systemd(1)-+-dbus-daemon(366,dbus)
|-login(413)---startx(436,user1)---xinit(475)-+-twm(482)
| `-Xorg(476)-+-{Xorg}(477)
|-urxvt(599,user1)---bash(600)
|-urxvt(1222,user2)---bash(1223)
5, And from now on you can start any program and access any file as two different users, but within the same Xorg login session.For a more secure setup, you could create one privileged admin user, one unprivileged login user, and one or more unprivileged application users.
Last edited by solskog (2020-11-09 01:34:58)
Offline
Well - the choice is yours, I don't think it matters. My personal choice would be to create a "normal" user called 'altair' in a default group called 'altair', etc. since the way you're using it is just like a regular user. Just expect that user to show up in GDM since its UID is greater than 1000.
I'll probably do that.
Is there any way to hide the user in GDM changing the UID to be below 1000?
Offline
Below it would be a system user, but you can use a gigantic UID to make it not appear iirc, like bigger than nobody’s UID...or in the range of systemd-homed
Offline
@Xwang: it's described in the GDM Wiki: Hide user from login list
Offline
When I execute kdesu -u altair command (where altair is the user created to run these applications and command is a bash script which sets some environment variables and then launches the GUI program) it does not run.
It works correctly if I previously execute xhost + or xhost -si:localuser:altair
If I have understood correctly the second option should be safer because it adds only the local user altair to the list of users which can connect to the xorg session owned by my regular user (I'm using a rootless Xorg). Is it correct?
Is it safe to add xhost -si:localuser:altair somewhere so that it is automatically executed every time I login to my regular user?
PS in any case I've discovered that it works better if I execute the xhost command in a console, the change user with su altair and there I execute the command because when the program opens other programs (for instance the browser to display the help pages) it works better than the kdesu.
Last edited by Xwang (2020-11-14 11:16:43)
Offline
Pages: 1