Page 1 of 1

App specific system call permissions

Posted: 14 Dec 2017 12:51
by Provo
Some very useful apps depend on the ability to run system calls. But for those system calls to be allowed, the commands must be added to /opt/z-way-server/automation/.syscommands manually by the local system administrator. What's more, it's not persistent between ZWay upgrades, so for each upgrade, one has to manually backup or reenter all its content.

Both from a user perspective and a security perspective, this is less than ideal. The user perspective is pretty obvious: unexperienced users will find the manual change of that file intimidating or confusing, and the rest of us will find it slightly tedious – although it's a quick operation. And when it has to be redone or copied for every upgrade, it gets even more tedious.

From a security perspective, the issue is that whatever is included in .syscommands can be run by any app – also malicious ones. This is not a major issue though, as all apps in the store are inspected by ZWay staff before it's approved.

My suggestion is to handle this issue more like it's done on for example Android, where each app has to ask for specific permissions, and the granting (or decline) of those permissions are associated with the app instance itself. So if some app needs to run ping, for instance, the user who installs the app needs to grant it the permission to run that specific system command. Any other app which also needs to run ping will also have to ask for permission to run ping, regardless of whether other apps have been granted the same permission. This should be persistent through system upgrades (but perhaps not through upgrades of the app itself – arguments could be made both ways there).

This would make it much easier for the users installing apps that depend on certain system commands and upgrading the system afterwards, and it would make a slight improvement to the security when permissions are app specific.

Re: App specific system call permissions

Posted: 17 Dec 2017 16:11
by PoltoS
Provo wrote:
14 Dec 2017 12:51
From a security perspective, the issue is that whatever is included in .syscommands can be run by any app – also malicious ones. This is not a major issue though, as all apps in the store are inspected by ZWay staff before it's approved.

My suggestion is to handle this issue more like it's done on for example Android, where each app has to ask for specific permissions, and the granting (or decline) of those permissions are associated with the app instance itself. So if some app needs to run ping, for instance, the user who installs the app needs to grant it the permission to run that specific system command. Any other app which also needs to run ping will also have to ask for permission to run ping, regardless of whether other apps have been granted the same permission. This should be persistent through system upgrades (but perhaps not through upgrades of the app itself – arguments could be made both ways there).

This would make it much easier for the users installing apps that depend on certain system commands and upgrading the system afterwards, and it would make a slight improvement to the security when permissions are app specific.
Nice idea - we will think about it. The problem is that we need to inspect for security each module even more precisely. This is not that easy as you can make a lot of bad things with bash scripts.

Indeed allowing a checkbox might be an option, but if this checkbox is set from Z-Way itself, any module can set it too (this is because the UI uses the API that can be altered by the module). So this is absolutelly unsecure.

Re: App specific system call permissions

Posted: 17 Dec 2017 16:12
by PoltoS
Dividing user from system .syscommands is a great idea indeed

Re: App specific system call permissions

Posted: 20 Dec 2017 13:02
by Provo
PoltoS wrote:
17 Dec 2017 16:11
Nice idea - we will think about it. The problem is that we need to inspect for security each module even more precisely. This is not that easy as you can make a lot of bad things with bash scripts.
That's sort of true, I guess. But as long as the module writers of today can get the user to add something in .syscommands, they can do the same bad things with bash scripts today.

The fact that granting permissions is easier could increase the security risk somewhat, but the fact that it's limited to that app would also have a positive effect security wise.
PoltoS wrote:
17 Dec 2017 16:11
Indeed allowing a checkbox might be an option, but if this checkbox is set from Z-Way itself, any module can set it too (this is because the UI uses the API that can be altered by the module). So this is absolutelly unsecure.
I see. I didn't think about that. Would be great if there was a way around that hurdle, though.