is it by possible to modify lede a bit...just to make the openvpn stop and start at the dashboard while it is lock via user .password...and the only thing they can access is ...openvpn changing server and openvpn commands like stop and start
You can disable LuCI and install a different webserver. In that you can either use CGI or a language like PHP to program your functionality per your wishes. The commands can be done from the alternate programming language by accessing the shell, where uci and all other shell commands can be used freely.
LP,
Jure
1 Like
You'd have to do quite a bit of work to do what you're proposing, and it would likely still be a security risk since OpenWrt is a single user OS. Why exactly are you trying to do what you're asking, as I can't think of a single use case as to why that would be necessary.
Use case is that the OpenWRT is a handheld device used to establish an OpenVPN connection for a laptop. 
I actually made one just like that. Also created interface where one can choose wireless network. It is not really that much work, because everything can be done with uci.
LP,
Jure
I don't know anyone who would recommend allowing unauthenticated root access, which is exactly what would have to be done to allow starting and stopping daemons without logging in.
Sudo has a config file for only allowing specific commands. Also a web interface only lets you do what it does and noting else. There is no prompt to enter commands, just 2 buttons.
And the only user capable of accessing this interface is the user who is directly connected to the device and should have root access.
There is no issue.
LP,
Jure
I'm aware of what can be configured with a sudo config, but OpenWrt is a single user OS and there's no way to get around that without completely rewriting the firmware from the ground up.
- Setting up sudo on OpenWrt, a single user OS, and setting up sudo on Ubuntu or another distro, a multi-user OS, are not the same things...
So theoretically if the web interface is poorly designed or there is an exploit in the webserver software. Then the user sitting behind the laptop can exploit his own gateway device. How terrible. 
LP,
Jure
uHTTPd is an insecure web server, that's why it should never be WAN facing.... nginx can't be used, and apache is resource hungry.
@jknee00 wasn't asking for their own access, but for others. Attempting to make a single user OS operate in the fashion of a multi-user OS is asking for headaches, security and otherwise... which is why there's no OpenWrt wiki for sudo. Everything in OpenWrt is controlled by root and root only.
I don't think @jknee00 was thinking WAN facing. Where do you see that implied?
This is very clearly LAN-only, where the user that owns the OpenVPN gateway can restart the connection if it is not working.
This is not possible with LuCI - you'd basically need to rewrite everything for such fine grained access control.
The most straight forward solution is what @dustwolf was proposing - write a different, dedicated UI which just does what you need.
You do not need to install a different webserver though, uhttpd handles CGI programs just fine.
Can you elaborate on that? What makes uhttpd less secure than an equivalently configured nginx or apache?
@jow Where would one configure security settings for uHTTPd? As far as I, and every other veteran OpenWrt user I've spoken with over the years, know, there are none, and, beyond serving LuCI, we never found an example of anyone using uHTTPd as a WAN facing web server, with everyone I've ever spoken to warning to never use it as a WAN facing web server.
-
/etc/config/uhttpdhas no security settings for securing the web server, beyond HTTPS redirect and specifying an SSL cert.
- Here's an example of one of the Nginx config files I use, and, as far as I know, uHTTPd supports none of the security implementations in the config
# ##::[[--- FreeBSD 11.1 Nginx NextCloud Config ---]]::## worker_processes 8; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile off; keepalive_timeout 65; ssl_protocols TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:ECDHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:!aNULL:!eNULL:!LOW:!3DES:!MD5:!SHA:!EXP:!PSK:!SRP:!DSS:!RC4; ssl_session_cache shared:SSL:10m; ssl_session_timeout 30m; ssl_prefer_server_ciphers on; server { listen 80; server_name 192.168.2.100; return 301 https://$server_name$request_uri; add_header X-Frame-Options "SAMEORIGIN"; } server { listen 443 ssl; server_name 192.168.2.100; ssl_dhparam /usr/local/etc/nginx/NextCloud-dh2048.pem; ssl_certificate /usr/local/etc/nginx/NextCloud.NAS.crt; ssl_certificate_key /usr/local/etc/nginx/NextCloud.NAS.key; add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload;"; add_header X-Content-Type-Options nosniff; add_header X-Frame-Options "SAMEORIGIN"; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none; add_header X-Download-Options noopen; add_header X-Permitted-Cross-Domain-Policies none; root /usr/local/www/nextcloud/; location = /robots.txt { allow all; access_log off; log_not_found off; } client_max_body_size 10240M; fastcgi_buffers 64 4K; gzip off; access_log /var/log/nginx-host.access.log; error_page 403 /core/templates/403.php; error_page 404 /core/templates/404.php; error_page 500 502 503 504 /50x.html; location / { rewrite ^ /index.php$uri; } location = /favicon.ico { access_log off; log_not_found off; } location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ { deny all; } location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) { deny all; } location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) { include fastcgi_params; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param HTTPS on; fastcgi_param modHeadersAvailable true; fastcgi_param front_controller_active true; fastcgi_pass unix:/var/run/php-fpm.sock; fastcgi_intercept_errors on; fastcgi_request_buffering off; } location ~ ^/(?:updater|ocs-provider)(?:$|/) { try_files $uri/ =404; index index.php; } location ~* \.(?:css|js)$ { try_files $uri /index.php$uri$is_args$args; add_header Cache-Control "public, max-age=7200"; add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload;"; add_header X-Content-Type-Options nosniff; add_header X-Frame-Options "SAMEORIGIN"; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none; add_header X-Download-Options noopen; add_header X-Permitted-Cross-Domain-Policies none; access_log off; } location ~* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ { try_files $uri /index.php$uri$is_args$args; access_log off; } } }
As far as I can see, none of these settings would secure against exploiting an actual bug in CGI program that runs as root. Its all anti-XSS fluff and some SSL fine tuning.
It would neither prevent shell injections, nor buffer overflows, fishing attempts or CRSF. When you called uhttpd less secure I assumed you meant some kind of actual overflows or authentication weaknesses, not some X-Header copy-pasta
It is true that you cannot configure arbitrary headers to be sent along with arbitrary responses, but nothing is preventing the actual application from emitting such headers, as it is done by LuCI for example: https://github.com/openwrt/luci/commit/11d0129f9661155dd2bd44cce5866726acd53433
That's not a WAN facing web server config, just one I use on LAN only. Has uHTTPd ever been tested against exploits, and if so, where can one that information?
- If OpenWrt's implementation of uHTTPd to serve LuCI is secure enough to be WAN facing and is able to have it's security customized, this information should be added to the appropriate wikis, however, there has never been any information regarding this in any OpenWrt wiki.... hence why everyone believes it should never be WAN facing.
The point is that one should always make a careful decision whether it makes sense to expose an administrative interface to the wan or not. The attack surface here is LuCI, not uhttpd. It does not matter if it is hosted by uhttpd, nginx, apache or anything else if it has an authentication bypass, an RCE or some other yet unfound bug.
The least likely attack vector is the web server itself and if there is an exploitable buffer overflow or similar, then nothing in the configuration settings mentioned above will make any difference.
4 Likes