Hi all,

I'm writing an application that will be run by a normal user, and it needs to be able to set the configuration for the network adapter (I don't love the idea, but the client wants what the client wants). Basically, the user, within this application, needs to be able to set the IP address (static or DHCP), subnet, etc.

The application is a Qt app written in Python. Naturally, I don't want them to run the app as root, so I need a normal user to be able to bring ethernet interfaces up and down, change settings, etc. Since this is an Arch Linux installation, this is normally done with netctl and the profile configuration files in /etc/netctl. However, netctl is a wrapper around systemctl, and you still need to be root to use it.

So, I figured the easiest thing to do would be to grant the user sudo permissions with NOPASSWD for /usr/bin/netctl. In my sudoers file, I just added
My normal user can then run "sudo netctl start|stop|status profile_name", and that user can bring the interface up and down without entering the password (which would be awkward in a GUI). If the user tries to do something nasty and run "sudo systemctl whatever", sudo won't allow it. So far, so good.

Now I'll just use the Python subprocess module to run netctl from my application. That seems secure enough, while still allowing the behavior the client needs. My question for you is... where do you see this blowing up in my face? Do you have any suggestions for improved security? Have I missed something in my sudo configuration that is a vulnerability? Better ideas altogether for how to handle this task? I'd appreciate any thoughts.

Thanks!

I'm not familiar with netctl though I did look through its web pages. If the user could modify a configuration file to launch a script of their choosing, then all bets are off. I couldn't see a way for that to be done with netctl, but again I am not familiar with it. Anyway, that's where I'd look.

If possible, I'd tighten it down to something like this:

Though it the profile_name varies to much, that might not be so practical.

1 members found this post helpful.

I would try to write a script which can run only the allowed commands (possibly processing command line arguments), and make that readonly. And users will be allowed to run only this script by sudoers.

1 members found this post helpful.

Thanks for your input!

I can keep the normal user on a short leash with sudo, and it sounds like that's the primary concern. If anyone else sees a problem with this method, please let me know. Thanks!

sudo itself is not "enough", you need to know what is really allowed (just an example: allowing to execute vi as root usually means full access, because you can execute any command from vi).