-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2017-03-14 19:04, 7v5w7go9ub0o wrote:
> On 03/14/2017 06:08 AM, Andrew David Wong wrote:
>> On 2017-03-12 15:09, 7v5w7go9ub0o wrote:
>>> On 03/12/2017 12:45 PM, Andrew David Wong wrote:
On 2017-03-11 19:41, Unman wrote:
> On Sat, Mar 11,
On 03/15/2017 02:24 AM, Chris Laprise wrote:
> On 03/14/2017 07:18 PM, Chris Laprise wrote:
>>
>> # Protect sh and bash init files
>> chfiles="/home/user/.bashrc /home/user/.bash_profile /home/user \
>> /.bash_login /home/user/.bash_logout /home/user/.profile"
>> touch $chfiles
>> chown -f root:roo
On Wednesday, March 15, 2017 at 3:15:15 PM UTC-4, cooloutac wrote:
> On Tuesday, March 14, 2017 at 7:22:04 PM UTC-4, Chris Laprise wrote:
> > On 03/14/2017 12:57 PM, cooloutac wrote:
> >
> > > yes I agree having to click yes in a dom0 popup will not be cumbersome
> > > for most. But is it that ea
On Tuesday, March 14, 2017 at 7:22:04 PM UTC-4, Chris Laprise wrote:
> On 03/14/2017 12:57 PM, cooloutac wrote:
>
> > yes I agree having to click yes in a dom0 popup will not be cumbersome for
> > most. But is it that easy for the devs to implement?
>
> Its already there, for a long time now. Th
Chris Laprise:
> On 03/14/2017 11:30 PM, sm8ax1 wrote:
>
>> Second, you mention that ~/.bin/sudo could be overwritten with the
>> attacker's binary or a script. I'm not sure I understand what you mean
>> exactly... the real sudo works by virtue of being owned by root with
>> suid. An attacker runn
On 03/14/2017 11:30 PM, sm8ax1 wrote:
Second, you mention that ~/.bin/sudo could be overwritten with the
attacker's binary or a script. I'm not sure I understand what you mean
exactly... the real sudo works by virtue of being owned by root with
suid. An attacker running as user cannot create a f
Chris Laprise:
> On 03/14/2017 09:13 AM, sm8ax1 wrote:
>
>
>> I still haven't heard any rebuttals against how sudo can help mitigate
>> attacks against the virtualization (persistence aside). Without sudo,
>> unprivileged processes can access /proc/xen/privcmd, raw sockets, memory
>> mappings, et
On 03/14/2017 07:18 PM, Chris Laprise wrote:
# Protect sh and bash init files
chfiles="/home/user/.bashrc /home/user/.bash_profile /home/user \
/.bash_login /home/user/.bash_logout /home/user/.profile"
touch $chfiles
chown -f root:root $chfiles
chattr +i $chfiles
The line break on that didn't
On 03/14/2017 06:08 AM, Andrew David Wong wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2017-03-12 15:09, 7v5w7go9ub0o wrote:
On 03/12/2017 12:45 PM, Andrew David Wong wrote:
On 2017-03-11 19:41, Unman wrote:
On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise wrote:
On 03/
On 03/14/2017 12:57 PM, cooloutac wrote:
yes I agree having to click yes in a dom0 popup will not be cumbersome for
most. But is it that easy for the devs to implement?
Its already there, for a long time now. The vm-sudo doc describes how to
enable it.
--
Chris Laprise, tas...@openmailbox
On 03/14/2017 09:13 AM, sm8ax1 wrote:
I still haven't heard any rebuttals against how sudo can help mitigate
attacks against the virtualization (persistence aside). Without sudo,
unprivileged processes can access /proc/xen/privcmd, raw sockets, memory
mappings, etc., and load kernel modules tha
On Tuesday, March 14, 2017 at 9:45:23 AM UTC-4, sm8ax1 wrote:
> sm8ax1:
> > Andrew David Wong:
> >> On 2017-03-13 22:09, Chris Laprise wrote:
> >>> On 03/12/2017 06:09 PM, 7v5w7go9ub0o wrote:
> On 03/12/2017 12:45 PM, Andrew David Wong wrote:
> > On 2017-03-11 19:41, Unman wrote:
> >>
sm8ax1:
> Andrew David Wong:
>> On 2017-03-13 22:09, Chris Laprise wrote:
>>> On 03/12/2017 06:09 PM, 7v5w7go9ub0o wrote:
On 03/12/2017 12:45 PM, Andrew David Wong wrote:
> On 2017-03-11 19:41, Unman wrote:
>> On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise
>> wrote:
>>
Andrew David Wong:
> On 2017-03-13 22:09, Chris Laprise wrote:
>> On 03/12/2017 06:09 PM, 7v5w7go9ub0o wrote:
>>> On 03/12/2017 12:45 PM, Andrew David Wong wrote:
On 2017-03-11 19:41, Unman wrote:
> On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise
> wrote:
>> On 03/11/2017 1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2017-03-13 22:09, Chris Laprise wrote:
> On 03/12/2017 06:09 PM, 7v5w7go9ub0o wrote:
>> On 03/12/2017 12:45 PM, Andrew David Wong wrote:
>>> On 2017-03-11 19:41, Unman wrote:
On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2017-03-12 15:09, 7v5w7go9ub0o wrote:
> On 03/12/2017 12:45 PM, Andrew David Wong wrote:
>> On 2017-03-11 19:41, Unman wrote:
>>> On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise wrote:
On 03/11/2017 11:56 AM, Unman wrote:
> On Sat
On 03/12/2017 06:09 PM, 7v5w7go9ub0o wrote:
On 03/12/2017 12:45 PM, Andrew David Wong wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2017-03-11 19:41, Unman wrote:
On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise wrote:
On 03/11/2017 11:56 AM, Unman wrote:
On Sat, Mar 11,
On 03/12/2017 12:45 PM, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2017-03-11 19:41, Unman wrote:
>> On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise wrote:
>>> On 03/11/2017 11:56 AM, Unman wrote:
On Sat, Mar 11, 2017 at 04:43:41PM +, sm8a
On 03/12/2017 12:45 PM, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2017-03-11 19:41, Unman wrote:
>> On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise wrote:
>>> On 03/11/2017 11:56 AM, Unman wrote:
On Sat, Mar 11, 2017 at 04:43:41PM +, sm8a
On Saturday, March 11, 2017 at 11:13:43 PM UTC-5, Chris Laprise wrote:
> On 03/11/2017 09:49 PM, cooloutac wrote:
>
> > Also what does Joanna mean by this statement on that page? " At the
> > same time allowing for easy user-to-root escalation in a VM is simply
> > convenient for users, especiall
Unman:
> On Sat, Mar 11, 2017 at 04:43:41PM +, sm8ax1 wrote:
>> 7v5w7go9ub0o:
>>>
>>>
>>> On 03/11/2017 12:10 PM, Alex wrote:
On 03/11/2017 12:14 PM, Chris Laprise wrote:
> On 03/11/2017 04:20 AM, Alex wrote:
>> the only really read-write directories (their changes are
>> actu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2017-03-11 19:41, Unman wrote:
> On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise wrote:
>> On 03/11/2017 11:56 AM, Unman wrote:
>>> On Sat, Mar 11, 2017 at 04:43:41PM +, sm8ax1 wrote:
7v5w7go9ub0o:
>>
>
> Yep! And ISTM t
On 03/11/2017 09:49 PM, cooloutac wrote:
Also what does Joanna mean by this statement on that page? " At the
same time allowing for easy user-to-root escalation in a VM is simply
convenient for users, especially for update installation."
The statement was originally written a long time ago. Q
On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise wrote:
> On 03/11/2017 11:56 AM, Unman wrote:
> >On Sat, Mar 11, 2017 at 04:43:41PM +, sm8ax1 wrote:
> >>7v5w7go9ub0o:
>
> >>>
> >>>Yep! And ISTM this is an argument for using dispvms to handle mail
> >>>(or any other WAN-exposed client/s
On Saturday, March 11, 2017 at 8:48:27 PM UTC-5, Chris Laprise wrote:
> On 03/11/2017 10:50 AM, cooloutac wrote:
> > I have always felt any level of security is useful no matter how trivial to
> > bypass.
> >
> > But I think the decision here for passwordless sudo is not cause privilege
> > escal
On 03/11/2017 10:50 AM, cooloutac wrote:
I have always felt any level of security is useful no matter how trivial to
bypass.
But I think the decision here for passwordless sudo is not cause privilege
escalation or non root persistence is trivial. Its because people like my
mother are not gon
On 03/11/2017 11:56 AM, Unman wrote:
On Sat, Mar 11, 2017 at 04:43:41PM +, sm8ax1 wrote:
7v5w7go9ub0o:
Yep! And ISTM this is an argument for using dispvms to handle mail
(or any other WAN-exposed client/server): start a dispvm; copy mail
client and mail "file" into it; do your mail; copy
On 03/11/2017 12:15 PM, Unman wrote:
The answer to this is encouraging users to make good use of isolation,
qube use and Qubes features. That isnt irresponsible. It's a way of
dealing with the problem. I think you would need to develop a much more
detailed argument to convince me that the answe
I usually just assume I'm protecting against randoms, not some super persistent
personal target I can't defend against anyways. So you always have to weigh
the efforts.
I hate to use the phrase threat model cause when it pertains to attackers there
is no such thing. Everything is in it so the
On Sat, Mar 11, 2017 at 08:49:10AM -0500, Chris Laprise wrote:
> On 03/11/2017 08:10 AM, Unman wrote:
>
> >
> >Anyway, it's a argument that could go on. I dont agree that "the
> >chance for improved security comes for free". It's absolutely clear that
> >Qubes aims to balance security with usabili
On Sat, Mar 11, 2017 at 04:43:41PM +, sm8ax1 wrote:
> 7v5w7go9ub0o:
> >
> >
> > On 03/11/2017 12:10 PM, Alex wrote:
> >> On 03/11/2017 12:14 PM, Chris Laprise wrote:
> >>> On 03/11/2017 04:20 AM, Alex wrote:
> the only really read-write directories (their changes are
> actually per
7v5w7go9ub0o:
>
>
> On 03/11/2017 12:10 PM, Alex wrote:
>> On 03/11/2017 12:14 PM, Chris Laprise wrote:
>>> On 03/11/2017 04:20 AM, Alex wrote:
the only really read-write directories (their changes are
actually persisted) are /home and /usr/local.
>>> That is enough to be able to persi
On Saturday, March 11, 2017 at 8:51:05 AM UTC-5, Chris Laprise wrote:
> On 03/11/2017 08:10 AM, Unman wrote:
>
> If it means a less attractive environment for script kiddies to raise
> hell--- chewing up resources, attacking other computers, creating
> footholds for more advanced threats--- then
hib0...@gmail.com:
> This part of the file system is not rewritten on every boot. Are you
> constantly somehow verifying your VM every boot, every 5 minutes, every web
> page load? Or are you restoring from a backup every boot or worse rebuilding
> the entire VM from a template every time you n
I have always felt any level of security is useful no matter how trivial to
bypass.
But I think the decision here for passwordless sudo is not cause privilege
escalation or non root persistence is trivial. Its because people like my
mother are not gonna constantly type their password in dozens
On 03/11/2017 12:10 PM, Alex wrote:
> On 03/11/2017 12:14 PM, Chris Laprise wrote:
>> On 03/11/2017 04:20 AM, Alex wrote:
>>> the only really read-write directories (their changes are actually
>>> persisted) are /home and /usr/local.
>> That is enough to be able to persist.
> Yes, and that doesn'
On 03/11/2017 08:10 AM, Unman wrote:
Anyway, it's a argument that could go on. I dont agree that "the
chance for improved security comes for free". It's absolutely clear that
Qubes aims to balance security with usability - some of the compromises
that have been made seem wrong to me, this isnt
On Sat, Mar 11, 2017 at 01:10:08PM +0100, Alex wrote:
> On 03/11/2017 12:14 PM, Chris Laprise wrote:
> > On 03/11/2017 04:20 AM, Alex wrote:
> >> the only really read-write directories (their changes are actually
> >> persisted) are /home and /usr/local.
> >
> > That is enough to be able to persis
On 03/11/2017 07:10 AM, Alex wrote:
On 03/11/2017 12:14 PM, Chris Laprise wrote:
On 03/11/2017 04:20 AM, Alex wrote:
the only really read-write directories (their changes are actually
persisted) are /home and /usr/local.
That is enough to be able to persist.
Yes, and that doesn't even need r
On 03/11/2017 12:14 PM, Chris Laprise wrote:
> On 03/11/2017 04:20 AM, Alex wrote:
>> the only really read-write directories (their changes are actually
>> persisted) are /home and /usr/local.
>
> That is enough to be able to persist.
Yes, and that doesn't even need root :) So, both having root or
On 03/11/2017 04:20 AM, Alex wrote:
the only really read-write directories (their changes are
actually persisted) are /home and /usr/local.
That is enough to be able to persist.
As the others already stated there could be problems for the actually
running session, i.e. the rogue command coul
On 03/11/2017 12:33 AM, hib0...@gmail.com wrote:
> Im sure this has been kicked into a pulp (considering the threads and
> the text in the sudoers files) but I am still perturbed by the
> argument that allowing unrestricted sudo to root in a DomU VM is
> "safe" and there is "no benefit" to disallow
On 03/10/2017 06:33 PM, hib0...@gmail.com wrote:
Im sure this has been kicked into a pulp (considering the threads and the text in the sudoers
files) but I am still perturbed by the argument that allowing unrestricted sudo to root in a DomU
VM is "safe" and there is "no benefit" to disallowing
Im sure this has been kicked into a pulp (considering the threads and the text
in the sudoers files) but I am still perturbed by the argument that allowing
unrestricted sudo to root in a DomU VM is "safe" and there is "no benefit" to
disallowing it. Perhaps I am misunderstanding something, I ha
44 matches
Mail list logo
