View original (French)

Restrict execution for selected GUI applications
lenainjaune -  

Hello everyone :D

First I dedicated this request on the Debian forum, but I think this concerns Linux in a broad sense. So the message can be redirected if necessary.

In a multi-user system, I want a given user to be limited to executing only a single graphical application (parental control), in my case Firefox. The others should, however, be able to use applications normally.

I'm not sure of the best approach to follow.

Recursively delete from root all execute rights for others (other) or better, invalidate them (see below), put users in groups and apply the desired rights?

OR:

Do the same thing as above on a case-by-case basis?

ET

Additionally, recursively modify the SUID/SGID/Sticky BIT of the concerned files so that when adding a new application, everything adapts automatically and modify /etc/adduser.conf so that new users are added to the normal group?

Instead of recursively modifying, can we invalidate the consideration of "other" rights?

---

I’m sure there is a much better-suited method.

If someone can help!

With adelphité,

lnj

I have questions for all your answers. (Woody Allen)
Knowledge and ideas belong to everyone (noosphere)!

1 answer

  1.  luckydu43

    Hello :-)

    Warning from the start, everything must be done in the user’s session. If the config overflows, it will impact other sessions. Always keep in mind the role and the goal of each action. A backup is necessary in my opinion before anything else.

    If it can reassure you, from all my hardening / kiosk mode research tonight, Mozilla was the nominal case. There is documentation and resources.

    I’m uneasy about the recursive rights story. The last time I did it, it was by mistake and we had to snap a snapshot.

    Firefox already offers such a mode.



    Firefox -kiosk (the parameter to have Firefox menus in kiosk mode)

    But it doesn’t replace hardening the session.

    We need to force the app (Firefox here) to fullscreen while blocking other actions.

    Guide 1 

    Guide 2 

    AppArmor helps block other apps

    There are other doors, blocking access to virtual terminals (CTRL+ALT+Fx) will close a few:

    Speaking of a shared infra, I recommend full backups. If not already done.

    If using btrfs, use the options of this amazing File System, otherwise a rsync-like tool. A completely different topic.

    Keep me posted ;-)

    The MAMAA don’t have oil but they have data!
    You feel my Big Data?
    Sacrifice a few freedoms for more security and you’ll lose THEM ALL.
    ALL YOUR DATABASE ARE BELONG TO US

    2
    1. lenainjaune Author Contributor
      Hello :)

      Yes, I’m lukewarm about replacing permissions recursively.

      The kiosk idea is not bad (Plan B) but it looks heavy to set up, especially to prevent exiting the kiosk.

      Since the user is a teen and not CLI-experienced, I wonder if confining the $PATH to the targeted folder wouldn’t already be a “band-aid” fix.

      Or then hiding the launchers and preventing their modification (I’m using XFCE4).

      I think there must be a practical solution that avoids the kiosk.
      0
    2. luckydu43
      @lenainjauneThere is a more practical option with XFCE, an integrated kiosk mode (link).

      As mentioned above, it’s a kiosk mode that locks the menu, the desktop, everything.

      On the menu side, simply minimize it to

      firefox -kiosk

      alone and delete all other .desktop files.

      And after all that, to block program launches (the absence of a launcher does not yet block launching programs), fapolicyd replaces AppArmor.

      PATH alone, I wouldn’t rely on: /usr/bin/vlc will still run even if vlc is no longer found in PATH. Same problem as in the paragraph above. A policy restricting application launches is required.
      0