Running pglgui as root

sansduck
2013-02-10
2013-02-16
  • sansduck
    sansduck
    2013-02-10

    Is there any difference (especially concerning security) between running pglgui as normal user (and using gksu/gksudo to actually start the filter) and running it directly as root?

    I know that I should avoid to start applications as root, but pgl needs root's power to change iptables anyway...

     
  • jre-phoenix
    jre-phoenix
    2013-02-13

    If there is any security hole in pglgui you will be exposed to it.
    With gksu only some functions get executed with root rights and thus are vulnerable.
    We still need to replace that gksu stuff with a policykit implementation.

    gksudo doesn't work well here, so I prefer to use gksu (with root password).

     
  • sansduck
    sansduck
    2013-02-14

    Thanks for answer. I'm glad you're still around.

    And what about pglcmd - it has to be run as root, right?
    Does this mean that system is potentially less vulnerable when running $ pglgui with gksu than # pglcmd?

     
  • jre-phoenix
    jre-phoenix
    2013-02-14

    pglcmd has to be run as root in the most cases (except show_config, test and a reduced version of status).

    I guess the biggest security problem of pgl is that pglcmd and pglgui both run scripts (files on harddisk). An attacker may manage to place malicious content in them.

    The biggest problem may be /tmp/execute-all-pgl-commands.sh which is constructed automatically by pglgui for whitelisting commands. This file is created with the rights of the user who runs pglgui, but is executed with admin rights. So if you run pglgui as user, an attacker who has gained control over the user account (but not yet over the root account) may use this file to gain root access. Bloody bad, isn't it?

    So you may be safer if you run pglgui as root to avoid this problem. On the other site, if there is any other security hole in pglgui, it gets worse by running pglgui as root.

    Generally this problem would be solved by implementing policykit, so that we don't have to use the /tmp/execute-all-pgl-commands.sh at all.
    Maybe there is an easy way to fix the problem in the short run.

     
  • sansduck
    sansduck
    2013-02-15

    This file is created with the rights of the user who runs pglgui

    And how about using just bare pglcmd?
    Security holes in pglgui should not be a threat to me if I'm using just pglcmd, right?
    And pglcmd doesn't use /tmp/execute-all-pgl-commands.sh, yes?

     
  • jre-phoenix
    jre-phoenix
    2013-02-16

    Correct, pglgui is completely additional. If you don't start it (or even don't install it), you will be safer. pglcmd does not use /tmp/execute-all-pgl-commands.sh.

    pglcmd executes the custom...insert|remove.sh scripts in /etc, but that should not pose a security risk, because files in /etc can only be created/modified by root.

    I'm not aware of any security problem with pglcmd.

    I can't judge the programming of pgld and pglgui for any further security holes.

    One big nice thing of pglgui that I like is that you can right-click on blocked IPs to add them to your whitelist instantly WITHOUT having to restart pgl. (You can do this manually, too: Issue the correct iptables command once (for immediate whitelisting), and add the IP to pglcmd.conf for permanent whitelisting.). But exactly this feature contains said security hole. - Now, if you don't want to use pglgui, and are to lazy/don't know how to issue the iptables command, you may choose to just add the IP to pglcmd.conf and restart pglcmd ... but this breaks a hole in the protection that is given to you by pgl because a restart leaves your machine unprotected for a few seconds. and every new connection opened in this few seconds will be allowed permanently, even after pgl is running again.

     
  • sansduck
    sansduck
    2013-02-16

    Thank you very much for comprehensive explanation.
    This is such a great project. It's a shame it's not in official debian repositories.