On 19/08/17 08:24, Per Jessen wrote:

Dave Howorth wrote:

...

On Fri, 18 Aug 2017 20:01:23 +0100 Paul Groves wrote:

...

Hi All,

I have come across the situation whereby I need to execute certain commands in my server management web page (written in PHP) that can only be run with sudo or as root. For example, adding / editing and removing root crontab entries.

What would be the correct and secure way to do this? Start by rewriting it in something other than PHP?

Design the system to have separate processes, connected using a special-purpose protocol that only permits the operations you intend. Right - and you can still do all of that with PHP.

Basically what is required is I will need to schedule jobs to run as the root user (like cron). I will also need to click a button in the web interface to run said jobs on demand (also running as root). Now I could perhaps tap into the system users for authentication with PHP. Then the user will be required to be in the sudoers group to run the root commands. I would prefer to go this route as I will only require the frontend web interface and when I add a new job I could prompt for the sudoer's password for authentication and write the line to the root crontab. Would this be a secure method? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 23 Aug 2017 12:10:12 +0100 Paul Groves wrote:

3. Command is then run as the logged in user's account using sudo. Thereby giving them root permission. e.g. sudo crontab -e

Of course this is insecure. As soon as anybody has any sudoer credentials they can insert whatever command they like into crontab and completely own the system. That's the whole point of separating the ability to execute pre-specified commands from the ability to create new commands. And a purpose-designed protocol is one way to do that. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 23/08/17 08:49 AM, Paul Groves wrote:

Every linux distribution I have ever seen allows all users in the sudo group to execute commands with sudo anyway by default. Seeing as the user will have to have to be in the sudo gorup to even access this web page, is it really any less secure than the same user ssh-ing into the system and doing it manually?

Well yes, you can set up sudo that way, "wildcarded". You can also set up ssh to allow root login and you can also set up the X-based GUIs to automatically login as root. But I don't recommend any of the above in a production system, no matter how convenient dropping security might be in your home system. A properly set up sudo config will address a specific list of users, or perhaps a group out of /etc/group, and limit them to a specific command or set of commands. This is not difficult. The distribution config file gives examples of how to do this. Failing that, go google for one of the many How-To pages about sudo. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 23/08/17 13:03, Vojtěch Zeisek wrote:

...

I would prefer not to have to go down the root of creating a system service if possible as cron can easily run scheduled tasks as root. All I need to do is to be able to add the commands to this file.

And of course giving the apache user root permission is not an option.

Would it be a good idea to do it like this?

1. The web interface will require users to be in the sudo group to log in. This way only users who can run sudo are allowed access to the web interface.

2. Then the user clicks a button to run a command. Box pops up asking for authentication. User enters their credentials.

3. Command is then run as the logged in user's account using sudo. Thereby giving them root permission. e.g. sudo crontab -e

Would this be any less secure than the user doing it from the command line? (the page is via https of course).

You have to remember I am dealing with windows administrators who seem allergic to command line stuff, hence the point of this management tool. Did You consider using Webmin? http://www.webmin.com/ It might be an option. You can set who can do what. I use Usermin to allow users to change their UNIX

Dne středa 23. srpna 2017 13:10:12 CEST, Paul Groves napsal(a): password on-line.

Last time I used webmin the way it worked was running an instance of apache with root privileges which I would say is less secure than my method of requiring users in the sudo group to authenticate every time a command is run. Unless this has been changed? Does anyone know how webmin runs root commands now? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 23/08/17 07:10 AM, Paul Groves wrote:

Would this be any less secure than the user doing it from the command line? (the page is via https of course).

They say that thee Internet is full of cats because no-one knows if you're a dog. Unlike SSH, HTTPS is _only_ an encrypted channel. What does that mean? Well in my Database of Dot Sig Quotes there is this; Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit card information from someone living in a cardboard box to someone living on a park bench. -- Gene Spafford What you describe is asking for authentication at the park bench end of things, after the encrypted channel has been set up. Anyone with a browser can get that far. The authentication you go on to describe is not particularly impressive. Someone could have hacked in to the browser making the connection before the connection was set up. It's just a password. As for 'doing it from the command line', most reasonable, modern *NIX breeds won't allow a root login from the Internet as a CLI. You have to be physically present at the console or log in and leave an audit trail using conventional accounts via SSH. Or you could simply set up your system so that it insecure by disabling those controls and run in CFM mode.

You have to remember I am dealing with windows administrators who seem allergic to command line stuff, hence the point of this management tool.

Windows administrators, in my experience, are not particularly security-savvy. Making an interface that is dumb enough for them opens up too many possibilities for some sophisticated hacker. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dne středa 23. srpna 2017 15:03:23 CEST, Paul Groves napsal(a):

On 23/08/17 13:30, Anton Aylward wrote:

...

As for 'doing it from the command line', most reasonable, modern *NIX breeds won't allow a root login from the Internet as a CLI. You have to be physically present at the console or log in and leave an audit trail using conventional accounts via SSH.

Unless they login as themselves type sudo before the command or use su then they can run it anyway.

...

Making an interface that is dumb enough for them opens up too many possibilities for some sophisticated hacker.

Which is why I have been asked to write this program. The interface will only allow executing specific commands and scripts and only by privileged users in the sudo group.

The reason I am posting is to find out a simple secure way of doing this.

Writing a system service could work but then that service will have full root access. I only want access granted to a handful of commands (such as adding entries in cron for maintenance jobs and creating new users).

Webmin can do that. You select particular user/group and allow what they can do. You must "just" trust Webmin... -- Vojtěch Zeisek https://trapa.cz/

On 23/08/17 14:59, Anton Aylward wrote:

On 23/08/17 09:03 AM, Paul Groves wrote:

...

...

The authentication you go on to describe is not particularly impressive. Someone could have hacked in to the browser making the connection before the connection was set up. It's just a password. The site is internal only and will never allow external connections. Your confidence in the, I suppose it is the firewall, must gladden the heart of many hackers :-) Not least of all those that know how to bypass same.

Then there's what amounts to variations on 'phishing' and other modes of subverting innocent and unsuspecting users to do things that they do not understand or think about the security implications of.

Finally there are the, well lets call them "malicious insiders". In gentler times these were the curious who wanted to learn how the 'system' worked and poked around. UNIX-of-old was remarkably open back then :-) But back then there wasn't so much of critical importance to protect, even from the non-malicious curious who might accidentally break something. These days we don't have that tolerance.

...

How could I log in securely if not using their password? Certificates, just like with SSH ?

One time codes sent to their phone ?

Proxy mechanism courtesy of Google or others ?

User specific challenge/response ?

Hardware token (aka 'dongle') ?

Perhaps the problem lines in the way the question is being asked. Why would YOU want to login in using THEIR password?

I will start from the beginning as there has obviously been some confusion. (sorry it is so long but I wanted to make sure I have covered everything): Currently there are 4 administrator users (IT Department). They are all in the sudo group on this server giving them access to run administrative tasks. For example the aforementioned users can log in via ssh (internal network only) using their credentials and run sudo useradd to create new users. (SSH is only open to the IT department IP addresses by the way). Now the problem lies in having to train all of these staff exactly which commands to type in. Especially every year when there are several hundred to do. (it is a school). The chance for human error is very high and it causes a lot of work correcting everything. So to save these problems, I have been asked to make a PHP based web console for the technicians to perform routine tasks such as this. Therefore eliminating the human factor. This server is already running apache for our internal portal. So I have made another virtualhost for the console. This virtualhost only allows connections from the IT department IP addresses (same as our sshd_config). Also the virtualhost uses a non standard port that has been opened in the firewall only for the IT department IP addresses. (Same as port 22 is configured for ssh). The virtualhost also required the user to log in and only allows users in the sudo group on this server (therefore only the 4 IT administrators). So now I have a php site that only the IT staff from the computers in the IT department can access. I have written a script for each of the required tasks. One example is creating users. So basically the goal is to have the IT admin log into the console on their browser. Go the the add user page. Check everything is correct for the new user(s) then clicks 'create' which then executes the add user script like so: sudo php /srv/script/addusers.php users_array where the users argument is a multi-dimensional array containing username, Full name, groups, home directory path etc... for each user to be created. Here lies the problem. The script will only work using sudo (because of useradd or chown, chmod and other commands which cannot be run as the www user). This is what I need help with. So I would like to run the script as the logged in IT Admin's account perhaps? The console could prompt them to authenticate and pass this information into the sudo command. Therefore when (lets call him Bob) Bob the technician does the above on the web page, the sudo command will be run under Bob's username and require bob's password. And because bob is in the sudo group the sudo command will then authenticate and run the script successfully. Exactly the same as Bob logging in and typing sudo php /srv/script/addusers.php users_array then entering his password for sudo. Let's be clear, I do not want to run apache as root (like webmin does) because this is a ridiculous idea in terms of security as I am sure you will all agree. apache should be run as it's own restricted user (usually www or wwwrun). Only the specified scripts should be allowed to run as root and only when a sudo user authenticates them to run. Hopefully this has been a clearer description of the problem? If anyone knows how I can go about this is a secure manner I would very much appreciate a solution. Or also any better ideas? Yours bashing-his-head-on-the-desk-ly Paul :-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Sorry that I have to quote so much of what you posted, but I think I need to make all this context clear. On 23/08/17 11:23 AM, Paul Groves wrote:

Now the problem lies in having to train all of these staff exactly which commands to type in. Especially every year when there are several hundred to do. (it is a school). The chance for human error is very high and it causes a lot of work correcting everything. So to save these problems, I have been asked to make a PHP based web console for the technicians to perform routine tasks such as this. Therefore eliminating the human factor.

This server is already running apache for our internal portal. So I have made another virtualhost for the console. This virtualhost only allows connections from the IT department IP addresses (same as our sshd_config).

Also the virtualhost uses a non standard port that has been opened in the firewall only for the IT department IP addresses. (Same as port 22 is configured for ssh).

The virtualhost also required the user to log in and only allows users in the sudo group on this server (therefore only the 4 IT administrators).

So now I have a php site that only the IT staff from the computers in the IT department can access.

I have written a script for each of the required tasks. One example is creating users.

So basically the goal is to have the IT admin log into the console on their browser. Go the the add user page. Check everything is correct for the new user(s) then clicks 'create' which then executes the add user script like so:

sudo php /srv/script/addusers.php users_array

where the users argument is a multi-dimensional array containing username, Full name, groups, home directory path etc... for each user to be created.

Here lies the problem. The script will only work using sudo (because of useradd or chown, chmod and other commands which cannot be run as the www user).

You are solving the wrong problem. The problem-about-the-doing lies in the way you have stated a solution. The solution is the last thing. "Why code? That's the last thing I will do!" yes, even after building your test framework! I suspect its a pernicious influence of the GUI model that comes with Windows, be it the Microsoft way of looking at things, or even Apple or YaST. The killer is in the step and repeat. Which a GUI forces on you. What you want to end up with is a extended /etc/passwrd (or equivalent) file with all those fields, username, Full name, groups, home directory path etc..., all there. So why not build that file and 'cat' it to the end ... oh, right, you need to create the home directories and put the templates in places, yamma, yamma, and 'adduser' does that[1]. So what I did back in those antediluvian ages was to build that file and submit it to a script that read each line, did verification on the contents for blatant stuff like out of band characters (cf "little Jimmy Fields"), clashes, and more, then ran useradd with that parameter list. Anything the checks rejected was, of course, logged. I later decided that a two-pass approach was better. Scan everything and reject the whole file unless it was internally consistent, did not clash with anything already configured and passed a series of security checks. I should mention that there are situations where GUIs are nice; dealing with email, browsing the web, full screen editing so you can see all you are writing (especially in word-processor mode!) and more -- it's wonderful. But when you are doing step-and-repeat, a GUI is a PIG! It is so totally the wrong way to do things that I can't comprehend what sort of mind wants to punish people by compelling them to do this tedious step-and-repeat. What do they think this is? Some sort of 15th century workhouse, they days before any automation? As far as I'm concerned the computer is there to serve me, and this sort of step and repeat approach is making the the user serve the computer. Thank you Microsoft and others for brainwashing so many people to think that such tedium is the norm. [1] IIR SUN found a way around that, which, wouldn't you know it, involved PAM. See the man page for 'pam_mount' to start with. IIR the home directory was created. on the server at the first login. I forget the mechanism. See also mechanism for 'mount on demand'. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org