Cockpit: new version

Hi guys :smiley: ,
in these weeks we worked on the new design (I hope the definitive) of the next NethServer admin dashboard AKA NethServer Cockpit.

The focus is:

  • Make the new NethServer modules self-contained as separated apps using the same style and design (the patternfly design).
  • Implement all functions server-side, itā€™s possibile to call them directly from terminal, using a CLI for example: nethserver <module> <action>
  • The interface use those functions to execute actions from GUI directly to the system, as usual

We developed the new version because the previous one had many nasty things:

  • It uses AngularJS 1.0 (thatā€™s quite old)
  • All the APIs are implemented via JavaScript, client-side
  • The System view has cards that are not easily navigable and not in the patternfly standars that instead promote left menu navigation

This new version:

  • It uses VueJS: that is modern, simple, lightweight and faster than AngularJS
  • All the APIs are implemented server-side with helpers, that the client calls using cockpit.spawn() as described above
  • The System has a left menu, fully navigable, and it will be used as a starting point to the next NethServer modules

You can test the new version by installing it from nethserver-testing repository:

yum install -y http://packages.nethserver.org/nethserver/7.5.1804/testing/x86_64/Packages/nethserver-cockpit-0.0.0-1.22.g71d412e.ns7.noarch.rpm

After installation navigate to https://your_server_ip:9090 and enjoy the new interface.

You can also view the First Configuration Wizard, navigate to https://your_server_ip:9090/nethserver-system#/wizard to see it.

:warning: It is only a mockup, without functionalities, but itā€™s used as a demostration of the new interface.

Feedbacks are welcome :blush:

Bye

8 Likes

Any chance on a 7.4 package? (untill all 7.5 modules are stable anyway)

Nope, but you can install also on 7.4 using the above URL :wink:

:clap::clap::clap:

Installed on 7.4.1708 (Final), updated to CentOS 7.5.1804 (Core) from Software Center.

1 Like

getting a ā€œnoting to updateā€ message:

yum install -y http://packages.nethserver.org/nethserver/7.5.1804/testing/x86_64/Packages/nethserver-cockpit-0.0.0-1.22.g71d412e.ns7.noarch.rpm
Loaded plugins: changelog, fastestmirror, nethserver_events
nethserver-cockpit-0.0.0-1.22.g71d412e.ns7.noarch.rpm | 2.3 MB 00:01
Examining /var/tmp/yum-root-tFkoLZ/nethserver-cockpit-0.0.0-1.22.g71d412e.ns7.noarch.rpm: nethserver-cockpit-0.0.0-1.22.g71d412e.ns7.noarch
/var/tmp/yum-root-tFkoLZ/nethserver-cockpit-0.0.0-1.22.g71d412e.ns7.noarch.rpm: does not update installed package.
Error: Nothing to do

But I donā€™t have the same interface.

Cockpit is an interactive Linux server admin interface.
Project website
Version 160.
Licensed under: GNU LGPL version 2.1

Do I need to remove the previous version of ns-cockpit?

Hi @robb,

I think yes!

yes @robb, remove the previous version:
yum remove nethserver-cockpit than install the new one :wink:

1 Like

AMAZING weā€™re going to have a shiny future :slight_smile:
Thanks @edoardo_spadoni for your job

1 Like

Ad I said other times, donā€™t use cockpit.spawn method but use cockpit.http one instead

The spawn method can be dangerous 'cause can executive any arbitrary command (a rm -fr * too) with the privileges of the logged in user.

My 2 ā‚¬c

1 Like

I found this blog post about cockpit security really interesting

Why .http is safer than .spawn?

This security issue makes me think about NPM dependencies @edoardo_spadoni: :thinking:

Wellā€¦ With it you can call and execute only what your API exposes.
Think about you expose a web app on WAN side and embrace the mantra ā€œtrust no oneā€

IIUC the article says that if the weakness is (in) the browser thereā€™s no API that can protect us. Itā€™s like having an hole in putty/sshā€¦

We must ensure that any JS code downloaded and executed by our browser is secure, like any Bash Perl and whatever script we run in our shell.

ā€¦thatā€™s why NPM dependencies (hell) are critical too

ā€¦ thatā€™s why weā€™d like a CLI too, as @edoardo_spadoni said above

Cockpit is a web shell like the bash shell, if you can run rm -rf / on bash, logged as root, you can run also the same command if logged on a web shell, the security problem is not cockpit.spawn.

If someone stole your rootā€™s password, it can runs arbitrary commands from web shell or bash shellā€¦

here weā€™re not talking about stolen passwordā€¦ if you use .spawn, youā€™re prone to run arbitrary commands

using .http you strongly limit the possibilities of an attack

in any case, itā€™s up to you

For the nethserver-cockpit module, we use only this NPM dependecies:

    "bootstrap-vue": "^2.0.0-rc.9",
    "c3": "^0.5.4",
    "d3": "^5.3.0",
    "jquery.flot": "^0.8.3",
    "moment": "^2.22.1",
    "vue": "^2.5.2",
    "vue-good-table": "^1.21.0",
    "vue-i18n": "^7.6.0",
    "vue-resource": "^1.5.0",
    "vue-router": "^3.0.1"

at the moment, it seems that they donā€™t have any security issues.

GitHub is very careful about that, it highlights the vulnerabilities in each packages, if it founds one.

1 Like

Itā€™s up on us! Please help me to understand how .http can be more secure. Do you have any link, article, vulnerability report that explains in which way it is a better approach to security?

wellā€¦

.spawn can execute any command available on the shell for the logged in user
.http can only make http calls to an rest api server

for me is a very different approach, 'cause in the second case you have another security layer, your API

Yes for sure:

Every software has its own bug, I donā€™t see in any of this approaches a security advantage on other.

(Sorry, I couldnā€™t resist! :smiley: Iā€™m going back to infrastructure stuff ā€¦)

1 Like

Think about this API example: password change

If the browser has a security hole, or malicious code is injected by other means the attacker can run the API password change and log in, no matter if .spawn or .http is used.

The article I posted above explains this concept far better than me.

We could ask cockpit devs to join this discussion. Next week Iā€™ll post our doubts on their ML. What do you think?

I never said that a REST API is bugless

thereā€™s a slight difference in WP and your product.

WPā€™s API is exposed and prone to attack

ideally speaking, your API is notā€¦ server manager use it, no other can

in any case, as I said, itā€™s up to you :slight_smile: