Cockpit: new version

Feature
,
#21

Dear All,

generally speaking every modern based webgui is working as a client itself against API libs (think about xenorchestra, an npm based xen web management gui, really well done).

I agree that login as root on a linux box (throught cli,gui,webgui) is generally a worst and bad pratice.

What about using Cockpit privilege escalation ? If I remember well, Cockpit permits and manages user privileges escalation through sudo or polkit api. So you do not need to login as root directly, but with a sudoer user, with a limited set of commands available (maybe you could limit commands avail…so you could parse and disallow things like “rm -rf” or cat /etc/password for example).

just my 2c

regards

6 Likes
#22

Your reply deserves more likes! Sorry I can give you only one :blush:

1 Like
#23

Davide, .spawn or .http cockpit api methods don’t make any differences security side speaking imho.

Cockpit.http only creates another http tunnel layer, but in the end it makes no differences on security side…different ways but same target: launching exec serverside scripts or even shell commands.

Just an idea…what about a chrooted jail environment ? .spawn or .http methods could write only config files to a secured env, then a parser -server side- checks, authorizes and exec these directives ?

I think about an approach that do not send shell commands directly to server but instead creates config files, parsed by the server itself (something like a resident process that continuously read a spool configs folder).

so :

web -> (.spawn .http) -> chroot env folder -> xml config file <- parser <- server process

I know it’s a complete different approach from actual NS behavior and architecture. So I think it involves a huge devel effort.

PS : Metasploit is calling :joy::joy::joy::joy:

2 Likes