Questions over questions

[gnanet]

@mitchellurgero I would like to ask you some things about your project, because it has good potential and would like to understand the logic behind some parts. I wanted to prepare these a bit better, but i hope you read this soon :)

You prepared pages where i think i know what your plan was, but some pages seem redundant to me, and i would be happy to clean up the code from leftover, and unused things. Also i could try to develop some of your planned parts, and to add some new features.

• What should be possible with the following pages: pages/nat.php pages/firewall.php

• Do you want this as a starting page for nat and firewall maybe? pages/network.php

• What is the goal of: pages/init.php pages/updates.php -- maybe is this already done in pages/check.php?

• Can we remove webconsole if we keep shell-in-a-box?

• Can we remove openrsd.md, because it seems to be an old version of README.md

• Functions and scripts that are used in more than one place, could be placed into functions.php: pages/network.php:$adapters_com = shell_exec("sudo bash ./app/scripts/adapters.sh"); pages/dashboard.php:$adapters_com = shell_exec("sudo bash ./app/scripts/adapters.sh");

  pages/users.php:$users = shell_exec("sudo bash ./app/scripts/listusers.sh"); app/auth.php:$users = shell_exec("sudo bash ./app/scripts/listusers.sh");

  pages/dashboard.php:$updates = shell_exec("sudo bash ./app/scripts/updates_list.sh"); pages/packages.php:$updates = shell_exec("sudo bash ./app/scripts/updates_list.sh");

Some of the shell scripts can be rewritten to only get raw data over shell, and parse the result in PHP, in pages/packages.php i am already testing one.

[mitchellurgero]

Hello, yes this has been a small project of mine for a couple years, so there are a LOT of parts left over from when I first started out with JS/PHP. To answer your questions (In order):

1. I wanted to implement a firewall type feature using IPTABLES, however after a lot of thought, the RPi is not going to cut it with this project since the whole project uses SUDO for a lot of pages (causing security to come into question) those pages can actually be deleted.

2. I think a network configuration page would be better than a firewall page. a UFW page would also be better instead of going the IPTABLES route.

3. init.php was for init.d, but was later changed and split into cron & services.php. updates.php was also changed to check.php. (I don't remember the logic for that, sorry!)

4. We can remove webconsole. Shell-in-a-box is MUCH better than my own modified version of what I was using.

5. openrsd.md can be renamed. It is an old page from a website I used to use, I'd like to keep it for archival purposes.

6. You can do that, like I said this project started a couple years ago when I was still a noob with PHP/JS. So any bug fixes and changes to optimize anything is completely welcome! (Hence why it is open source!)

If you want, https://urgero.org is my current site with contact details, add me on FB Messenger and we can talk more in detail if you like.

Also - Thanks for your hard work! It feels amazing that someone else is taking an interest in this project as it is one of my bigger projects I have worked on next to ADB WebUI. :)

[gnanet]

Thank you for the answers, i wanted to make sure that you don't feel your project raped by my changes. For example, i have no issue with openrsd.md , keeping it is no question. If i can have a last question here:

/null which contains a transcript of an "apt-get update" do you want to keep it? ;)

Ofcourse i will add you on FB, but i will try not to disturb you too much :D

Talking about security, i have some ideas that i will try out then,

[mitchellurgero]

If you can figure out how to use sudo without the need for the sudoers file to allow all commands without password then be my guest! I am open to suggestions.

And no we are good, it's open source just for this purpose. nah bother me as much as you like, I am in the US though so IDK what that does for timing but theres that.

also for /null, we can delete that as well - it was a mistake that should not have been saved to git lol

[gnanet]

I am looking for alternatives, until i find anything, im still for sudoers. BUT: recent Raspbians have /etc/sudoers.d/ and as you maybe have seen, i included in the stretch instructions already a brutal one echo "www-data ALL=(ALL) NOPASSWD: ALL" | sudo tee --append /etc/sudoers.d/010_pi-nopasswd

the mit-term solution would be to declare one folder in the project, that contains all the scripts that need to be run with sudo and in the sudoers file we set that path for NOPASSWD only.

For example like this: echo "www-data ALL=(ALL) NOPASSWD: /var/www/html/openrsd/app/privscript" | sudo tee --append /etc/sudoers.d/020_openrsd-nopasswd

Also i will try to replace shell_exec solutions, if there is a workaround that does not need sudo, or even shell_exec.

[mitchellurgero]

shell_exec will 100% be needed or we can move to using expect to try and input the users password, but that requires storing the password in plaintext server side. shell_exec is required by PHP to execute an application and return the output into an array or PHP object unlike "exec". I will be keeping shell_exec unless you can come up with a better solution?

for the sudoers, I had instructions for changing the user and group of apache to "pi" because that user is already NOPASSWD for sudo. so doing it for www-data is pointless imo.

The issue with your mid-term solution is that it assumes the same folder for all devices which may not be the case here since the install can be done in any /var/www directory (/var/www/openrd or /var/www/html as an example).

[gnanet]

I opted for allowing the common webserver user to sudo some script-folder, rather than changing the run-user of a webserver, to allow the RPi be used as a common webserver later.

The path differences that may rise, but the basic setup instructions can emphasize this. I already started to think about a kind-of install script, that does the required steps in an intelligent way (for example the curl -based one-line for node.js )

A way around all this would be to spawn a separate webserver with root privs for openRSD exclisively on a separate port (similar to webmin)

ofcourse shell_exec cannot be replaced totally,

but for example getting the interfaces and their IP we dont need sudo, a simple ip a s tells the needed data, and preg_match_all does the rest.

And with a bit of extra rounds in /proc/net/fib_trie /proc/net/dev and /proc/net/route it is possible to connect the IP addresses found with devices without the need of shell_exec ;)

[mitchellurgero]

If you make a merge request and it works, I'll accept it. Anything to better the security is good in my book.

As for the spawning of webserver - PHP has a built in one we could use. php -S localhost:8900 -t /path/to/openrsd/install

Of which can be automated 100% with a curl install script. I like the sound of this actually.

This seems promising for that too: https://stackoverflow.com/questions/39842170/load-balancing-php-built-in-server

[gnanet]

I think we can close this, later in a separate issue we may collect requirements for

• installer script
• good solution for self contained webserver (because your linked stackoverflow article is already about the issues with sequentially served content)

[mitchellurgero]

Load balancing with ncat (or nginx?) and PHP's built in web server seems to be a decent solution but I will dive deeper then.