qubes.RequestRpmInstallinDom0

[rootkovska]

Usecase: an AppVm downloading a new Qubes Cfg Package (e.g. for setting up YubiKey for Qubes login, or a wallpaper, or whatever) via a nice Internet-connected Appstore-like UI, later offering this RPM for installation and deployment in Dom0.

Of course Dom0 would first verify the digital signature on the RPM offered, same way as it currently does for the Dom0 updates, and install only if signature correct, plus user confirms operation.

Consider also to move the whole Dom0 updating to use this method, i.e. the whole logic triggered by a predefined AppVM rather by Dom0. Of course there is a risk of DoS (i.e. not delivering updates to Dom0 if the AppVM got compromised), but this is the case today anyway.

[marmarek]

I think this is really bad idea. This would allow AppVM to trick the user to install potentially harmful package. Lets use os-prober as an example, but there are probably a lot more such harmful packages in the Fedora repositories.

I think the better approach would be to implement #1939 , which may include similar service (qubes.RequestSaltFormulaInstall). The formula would be of course signed (after being reviewed by us). And such formula may request some package being installed of course.

[marmarek]

I think this is really bad idea. This would allow AppVM to trick the user to install potentially harmful package. Lets use os-prober as an example, but there are probably a lot more such harmful packages in the Fedora repositories.

I think the better approach would be to implement #1939 , which may include similar service (qubes.RequestSaltFormulaInstall). The formula would be of course signed (after being reviewed by us). And such formula may request some package being installed of course.

[rootkovska]

Only pre-defined AppVM would be allowed to issue the service (enforced via qrexec policy).

[rootkovska]

Only pre-defined AppVM would be allowed to issue the service (enforced via qrexec policy).

[marmarek]

Still, I think this is a step in wrong direction. This will ease (and maybe even encourage) users/admins to easily break system security. By implementing this service we'll be relying on some network-connected AppVM to not misbehave in order to preserve dom0 isolation. The fact it is only a single AppVM isn't really comforting.

[marmarek]

Still, I think this is a step in wrong direction. This will ease (and maybe even encourage) users/admins to easily break system security. By implementing this service we'll be relying on some network-connected AppVM to not misbehave in order to preserve dom0 isolation. The fact it is only a single AppVM isn't really comforting.