subuser-security
Can Subuser have Android Marshmallow style permissions
In Android Marshmallow a prompt is shown like
So could Subuser also have something like this which shows a similar prompt (Which should use the GTK theme) instead of having a permissions file (or we could have both)
Permissions files are a good thing and are here to stay. They create a clear and auditable list of what permissions are granted. They lets you see in one place, everything that can go wrong/be taken advantage of.
However, I do understand that on-demand permissions could have some security benefits. For example, a video calling program doesn't need access to the webcam unless a video call is taking place, but in order to gain those benefits, there needs to be a way to take away web-cam access at the end of the call. This would be possible, but it would require some extra interface, perhaps an icon in the system tray, or at the bottom of the windows of the program which was granted the permission. Does android have such an interface, for revoking temporary permissions?
Unfortunately, such an on-demand permission scenario is not at all easy to implement with pre-existing programs like Skype or even the open source Cheese. Right now, with subuser, you don't have to modify programs to run them. Linux programs currently don't request access to things like the webcam, they just use them, if they are available. So this isn't easy to implement without subuser adding some API that would be used only by special "subuser programs". I don't want to force application authors to change their implementation details just for subuser. At least not yet, when subuser is not a popular solution.
One more thing: There will never be a "do not ask again" check box. This would be a security flaw in my mind, because the user typically checks such a box, not out of desire to grant a permission perminantly, but out of annoyance at having be asked so many times. I might, however, add an "edit permissions" button.
In the future, if this type of feature gets added, each of the permissions that could be asked for would have three settings: Deny, Ask, and Grant. This way, programs that have no business asking for permissions cannot do so. Imagine that you have an irssi subuser which is able, based on analysis of network activity, determine when Skype is receiving a phone call. It then requests a webcam permission, and you see a dialog:
--------------------------------------
¦Grant irssi access to the webcam?
¦
¦ Allow ¦ Deny ¦
¦-------------------------------------
The user may click Allow, not realizing that it is irssi and not Skype that is asking.
Another problem with allowing programs to ask for permissions without those permissions being explicitly listed is auditablility. As I already stated, I want the permissions list to be a complete list of everything that can possibly go wrong from a security standpoint.
Finally, allowing programs to ask actually exposes an API, and all API surface area is a risk to security.
I would therefore never let a program even ask unless it was given permisison to do so.
I think we should have it so if the permission is listed as ask (like in a video call app) then it shows a prompt.
If the permission is allowed then it allows (as usual).
If it is denied then it denies the permission.
If it is not listed then it asks
@timthelion I know a bit of Python so I would like to know the location of the code where it blocks the permission (which file).Then maybe I can submit a pull request
Permissions aren't blocked but granted. Take a look at the two files listed here: http://subuser.org/developers/common-tasks.html#adding-a-new-permission
On 04/11/16 12:02, Suici Doga wrote:
@timthelion https://github.com/timthelion I know a bit of Python so I would like to know the location of the code where it blocks the permission (which file).Then maybe I can submit a pull request
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/subuser-security/subuser/issues/283#issuecomment-208265376
@timthelion I looked at the runtime file and I found a lot of methods. Which one does the granting
They all do, pretty much. Permissions are granted by passing arguments to Docker, and the runtime file builds that list of arguments. https://github.com/subuser-security/subuser/blob/master/logic/subuserlib/classes/subuserSubmodules/run/runtime.py#L108 getPermissionsFlagDict is the most important one though.
Tim
On 04/12/16 04:10, Suici Doga wrote:
@timthelion https://github.com/timthelion I looked at the runtime file and I found a lot of methods. Which one does the granting
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/subuser-security/subuser/issues/283#issuecomment-208664288
@timthelion So do I edit only getPermissionsFlagDict or do I have to edit the other methods too
@timthelion Edit it so I can show a message box.You say that other methods are used too before.Is getPermissionsFlagDict the only one or do I have to edit the others
Permissions are granted when the subuser is started. So that message box would appear when you launch the subuser, not when the permission is needed.
On 04/12/16 14:43, Suici Doga wrote:
@timthelion https://github.com/timthelion Edit it so I can show a message box.You say that other methods are used too before.Is |getPermissionsFlagDict| the only one or do I have to edit the others
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/subuser-security/subuser/issues/283#issuecomment-208885939
Unfortunately, so long as we use Docker, which doesn't allow for changing container permissions after launch, this isn't possible. Once the move to runc takes place many previously impossible things become possible.
@SuicSoft there have been many issues about this open(or closed) for years:
- https://github.com/docker/docker/issues/9849
- https://github.com/docker/docker/issues/2045
- https://github.com/docker/docker/issues/3285
The list goes on...
I believe that you are refering to "only through the API, as you can pass bind-mounts and volumes-from on start." But this doesn't allow for modifying RUNNING containers, it only allows for modifying "containers".
@timthelion So running containers can't be modified .The problem with subuser it needs docker
@SuicSoft yes, in the future, subuser will not use Docker and things will move along more quickly, be better, and break less often.
The 0.5 line uses Docker, the 0.6 line will use runc. However, there are still a lot of pre-requisits that I want to get down before I can start working on the 0.6 line. I want to use de-duplicated, content adressable storage with eficient content adressable data transports/transfer (The current candidate for this storage backend is IPFS). I also have to make sure that I know how to do secure networking with runc. So I'm not sure how long it will take me, and that is why I'm working hard on the 0.5 line to get it polished enough that it can last the wait.
On 04/17/16 03:44, Suici Doga wrote:
@timthelion https://github.com/timthelion When will this happen
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/subuser-security/subuser/issues/283#issuecomment-210936753