to firejail or not to firejail

[pixel fairy]

firejail , https://firejail.wordpress.com/

can be used to restrict and/or contexualize a process with namespaces. i was thinking of restricting ssh connections with it to prevent the free privilege escalation qubes gives malicious apps in case of an exploitable hole in ssh. but, firejail itself is more code to exploit, and though it matters less in qubes, setuid.

so what thinks all of you? worth the extra attack surface?

was also thinking of using firejails logging to flag attempts at sudo etc as another means to flag a host with problems. this again, means extra code that itself could be exploited.

[Eric]

The question as always is, what are you protecting? If it's your user data, compartmentalize differently. If it's some kind of root privilege escalation, that's a lost cause, as the vm sudo page explains. If it's some kind of malware that could get written with root privileges, well, that gets erased by rebooting the VM, unless it's persistent in your user data, but if it is, it's incredibly unlikely to be runable (at least not without explicit user action).

I raise these questions because the answer to many of the "OMGWTFBBQ passwordless sudo" threads that appear every so often, come back down to either "whatever you're proposing wouldn't make a difference read the doc again" and "are you sure you read the doc and understood why the decision was made the way it was?"

I don't disagree that hardening VMs in general is good practice; I am very sad that Subgraph is MIA and grsecurity patches are no longer available, since they were a great way to harden Linux VMs.

In your particular situation, a good compromise might be the dom0 escalation prompt, described at the end of the VM Sudo documenation (no additional code, really, and at least *some* peace of mind that...it would take a few more seconds of extra work to find a root privilege escalation that would get around the prompt requirement?)

[pixel fairy]

On Monday, August 28, 2017 at 10:46:22 PM UTC-7, Eric wrote:
> The question as always is, what are you protecting? If it's your user data, compartmentalize differently. If it's some kind of root privilege escalation, that's a lost cause, as the vm sudo page explains. If it's some kind of malware that could get written with root privileges, well, that gets erased by rebooting the VM, unless it's persistent in your user data, but if it is, it's incredibly unlikely to be runable (at least not without explicit user action).
>
> I raise these questions because the answer to many of the "OMGWTFBBQ passwordless sudo" threads that appear every so often, come back down to either "whatever you're proposing wouldn't make a difference read the doc again" and "are you sure you read the doc and understood why the decision was made the way it was?"

this wasnt specifically because of the passwordless sudo. its a general access control and hardening thing. i see firejail as complementary to qubes-os. ssh shouldnt access the x server. firefox shouldnt write outside of its own folder and Downloads. neither should shell out and call sudo. when they do, or try to, id really like to know about it. firejail can log such access, and you can have another process follow that log to alert you.

but having firejail do that, and watching that log, are more processes, more attack surface.

to add to extremely unlikely, ive only known of one ssh client exploit in the wild, and i think it was over 10 years ago.

>
> I don't disagree that hardening VMs in general is good practice; I am very sad that Subgraph is MIA and grsecurity patches are no longer available, since they were a great way to harden Linux VMs.

subgraph was a neat idea. looked at it for a friend whos laptop lacked hypervisor extensions, but couldnt get it to work.

>
> In your particular situation, a good compromise might be the dom0 escalation prompt, described at the end of the VM Sudo documenation (no additional code, really, and at least *some* peace of mind that...it would take a few more seconds of extra work to find a root privilege escalation that would get around the prompt requirement?)

looked over that out of curiosity since it seemed like a neat idea, but never tried it.

[pixelfairy]

just remembered, a couple other ssh exploits, and googled for them, found a couple others. so that does come up once in a while.

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/RnKRH0lIP_c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ab05b325-683f-417d-9862-1833fe867678%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Laprise]

On 08/29/2017 03:54 AM, pixel fairy wrote:
> On Monday, August 28, 2017 at 10:46:22 PM UTC-7, Eric wrote:
>> The question as always is, what are you protecting? If it's your user data, compartmentalize differently. If it's some kind of root privilege escalation, that's a lost cause, as the vm sudo page explains. If it's some kind of malware that could get written with root privileges, well, that gets erased by rebooting the VM, unless it's persistent in your user data, but if it is, it's incredibly unlikely to be runable (at least not without explicit user action).
>>
>> I raise these questions because the answer to many of the "OMGWTFBBQ passwordless sudo" threads that appear every so often, come back down to either "whatever you're proposing wouldn't make a difference read the doc again" and "are you sure you read the doc and understood why the decision was made the way it was?"

I believe the direction of the recurring discussion has been following a
somewhat different arc. Joanna and Marek have lately been receptive
(even supportive) to internal domU security... at least ways to enable
it. I think the impetus for the shift boils down to these points:

1. VMs shouldn't passively amass malware, even if its not a threat to
Xen isolation; its a nuisance at best that can affect other
computers/devices. DispVMs help in prevention, but not for many normal
PC usage scenarios.

2. DomU OS's have unobtrusive security features ready for use with
little or no burden to us:

With 'vmsudo' auth prompts configured, using basic domU security is very
easy: Say yes/no to the prompt shown in dom0. This is not about
passwords in AppVMs.

3. Such domU defenses, while judged to be inferior in general, do
receive patches and could allow Qubes systems to thwart attacks
ultimately aimed at the hypervisor. This matters even if Linux, etc.
remains "swiss cheese" and saves our bacon in only a small percentage of
scenarios.

4. Qubes' read-only templates provide a basis for anti-threat
persistence measures like 'Qubes-VM-hardening'[1], but only if domU auth
is enabled.

5. Xen security was not quite as good as was hoped.


Guest OS's supposedly compete on the basis of security, so its probably
best to let them do their job in this regard. Especially if all that
requires from us is to not switch off security or a little bit of PAM
configuration.

> this wasnt specifically because of the passwordless sudo. its a general access control and hardening thing. i see firejail as complementary to qubes-os. ssh shouldnt access the x server. firefox shouldnt write outside of its own folder and Downloads. neither should shell out and call sudo. when they do, or try to, id really like to know about it. firejail can log such access, and you can have another process follow that log to alert you.
>
> but having firejail do that, and watching that log, are more processes, more attack surface.
>
> to add to extremely unlikely, ive only known of one ssh client exploit in the wild, and i think it was over 10 years ago.

FWIW, AppArmor does work with Qubes VMs and doesn't revolve around a
special launcher.


[1] https://github.com/tasket/Qubes-VM-hardening/tree/systemd

--

Chris Laprise, tas...@posteo.net
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886