Re: [qubes-users] Re: to firejail or not to firejail

2017-08-30 Thread 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

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/378ae919-6e19-16bd-58de-205093399c27%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: to firejail or not to firejail

2017-08-29 Thread 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.

On Tue, Aug 29, 2017 at 12: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?"
>
> 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.
>
> >
> >
> > On Monday, August 28, 2017 at 9:22:48 PM UTC-7, pixel fairy wrote:
> > > 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.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CACr%3DtZdi_du%3D82Ym0wwqVSLg5Hzw8PwzsVHXKdV23Nd3RJDgjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: to firejail or not to firejail

2017-08-29 Thread 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.

> 
> 
> On Monday, August 28, 2017 at 9:22:48 PM UTC-7, pixel fairy wrote:
> > 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.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@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.

[qubes-users] Re: to firejail or not to firejail

2017-08-28 Thread 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?)


On Monday, August 28, 2017 at 9:22:48 PM UTC-7, pixel fairy wrote:
> 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.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/89f60e76-177e-42fe-ba21-2313bff42b2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: to firejail or not to firejail

2017-08-28 Thread cyberian 
>the free privilege escalation qubes gives malicious apps
I dont believe Qubes gives malicious apps free privilege escalation, but if you 
want a password to be required for privilege escalation on the default user, or 
any user, you should just be able to require password for sudo i believe its in 
the documentation here: https://www.qubes-os.org/doc/vm-sudo/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1cca2b2b-a7c9-44d1-982b-4bdffe6208a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.