Hi Valdis,
On Wed, 19 Sep 2007, [EMAIL PROTECTED] wrote:
>
> On Wed, 19 Sep 2007 01:16:28 EDT, Kyle Moffett said:
>
> > I am assuming that if the laptop has sufficiently important data on
> > it to warrant the above steps then I am also clueful enough to:
> >(A) Not carry the laptop arou
On Wed, 19 Sep 2007, J. Bruce Fields wrote:
>
> Uh, is there somebody else that feels they're being enlightened by this
> discussion?
Ok, probably I got a bit too harsh with Kyle there. But what I don't
understand is why is it so hard for someone to accept they're wrong
on this list, thank the
On Wed, 19 Sep 2007 01:16:28 EDT, Kyle Moffett said:
> I am assuming that if the laptop has sufficiently important data on
> it to warrant the above steps then I am also clueful enough to:
>(A) Not carry the laptop around unsecured areas,
>(B) Keep a close enough eye on it and be aware
On Wed, Sep 19, 2007 at 07:42:20PM +0530, Satyam Sharma wrote:
>
>
> On Wed, 19 Sep 2007, Kyle Moffett wrote:
> >
> > > [all sorts of crap about spies in washington needing stronger protection
> > > than your average consumer]
> >
> > [snip]
> >
> > [...] all the bullcrap about foreign intelli
On Wed, 19 Sep 2007, Kyle Moffett wrote:
>
> > [all sorts of crap about spies in washington needing stronger protection
> > than your average consumer]
>
> [snip]
>
> [...] all the bullcrap about foreign intelligence
Hehe, again, *you* started all the "bullcrap" about foreign "governments"
in
On Sep 19, 2007, at 08:16:30, Satyam Sharma wrote:
[all sorts of crap about spies in washington needing stronger
protection than your average consumer]
Well no duh. I think most of the 4-year-olds I know could have told
you that. What sense does it make to give a spy all sorts of fancy
e
On Wed, 19 Sep 2007, Kyle Moffett wrote:
>
> On Sep 18, 2007, at 19:44:59, Satyam Sharma wrote:
> >
> > The whole *point* here is to secure against physical access -- then how can
^^^
> > you assume "barring disassembling the system"?
On Sep 18, 2007, at 19:44:59, Satyam Sharma wrote:
On Thu, 6 Sep 2007, Kyle Moffett wrote:
On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote:
The question of how to protect against som
On Fri, 7 Sep 2007, Kyle Moffett wrote:
>
> So you can't draw any relationships between "Protect the end-user" with
> "Protect the device FROM the end-user", the former can be done very reliably
^^^ *attacker*
> to whatever level of risk-reduction you need and the lat
On Thu, 6 Sep 2007, Kyle Moffett wrote:
>
> On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
> >
> > On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
> > >
> > > On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote:
> > > > The question of how to protect against someone with *physical
On Fri, 7 Sep 2007, J. Bruce Fields wrote:
>
> On Fri, Sep 07, 2007 at 01:32:52AM +0200, Trond Myklebust wrote:
> > Sorry. Of course, you have to copy the entire /lib, etc. onto the tmpfs,
> > but you get the gist
> >
> > The point is that it is easy to subvert userspace if you have enough
On Thu, 6 Sep 2007, J. Bruce Fields wrote:
>
> On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote:
> > Oh and btw, note that we're talking of the (lack of) security of a
> > "running kernel" here -- because across reboots, there is /really/
> > *absolutely* no such thing as "kernelspa
On Fri, Sep 07, 2007 at 01:32:52AM +0200, Trond Myklebust wrote:
> Sorry. Of course, you have to copy the entire /lib, etc. onto the tmpfs,
> but you get the gist
>
> The point is that it is easy to subvert userspace if you have enough
> privileges. In the above example it may not be entirely
In article <[EMAIL PROTECTED]> you wrote:
> So you can't draw any relationships between "Protect the end-user"
> with "Protect the device FROM the end-user", the former can be done
> very reliably to whatever level of risk-reduction you need and the
> latter can't practically be done at all.
On Sep 07, 2007, at 01:14:09, Trond Myklebust wrote:
On Thu, 2007-09-06 at 20:56 -0400, Kyle Moffett wrote:
Umm, I did say "encrypt the root filesystem", didn't I? Booting
my laptops this way follows this procedure:
1) Enter BIOS boot menu
2) Insert /boot CDROM
3) Select the "CDROM"
On Thu, 2007-09-06 at 20:56 -0400, Kyle Moffett wrote:
> On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
> > On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
> >> Actually, that's a fairly simple problem (barring disassembling
> >> the system and attaching a hardware debugger). You en
On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
Actually, that's a fairly simple problem (barring disassembling
the system and attaching a hardware debugger). You encrypt the
root filesystem and require a password to boot (See: LUKS
On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote:
On Thu, Sep 06, 2007 at 01:44:05PM +0530, Satyam Sharma wrote:
Like Trond said, there are very high number of ways in which
privileged userspace can compromise a running kernel if it really
wants to do that, root-is-God has always been *the
On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
> On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote:
> > On Thu, Sep 06, 2007 at 01:44:05PM +0530, Satyam Sharma wrote:
> >> Like Trond said, there are very high number of ways in which
> >> privileged userspace can compromise a running ker
On Fri, 2007-09-07 at 01:21 +0200, Trond Myklebust wrote:
> On Thu, 2007-09-06 at 11:11 -0400, J. Bruce Fields wrote:
> > On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote:
> > > Oh and btw, note that we're talking of the (lack of) security of a
> > > "running kernel" here -- because ac
On Thu, 2007-09-06 at 11:11 -0400, J. Bruce Fields wrote:
> On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote:
> > Oh and btw, note that we're talking of the (lack of) security of a
> > "running kernel" here -- because across reboots, there is /really/
> > *absolutely* no such thing as
On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote:
> Oh and btw, note that we're talking of the (lack of) security of a
> "running kernel" here -- because across reboots, there is /really/
> *absolutely* no such thing as "kernelspace security" because the superuser
> will simply switch
On Thu, Sep 06, 2007 at 01:44:05PM +0530, Satyam Sharma wrote:
> /dev/kmem was just an example -- IMHO differentiating between kernel and
> userspace from a security p.o.v. is always tricky.
The things that come to mind are /dev/kmem and module-loading. What
else is there? And what is it that ma
On Thu, 6 Sep 2007, Satyam Sharma wrote:
>
> On Thu, 30 Aug 2007, J. Bruce Fields wrote:
>
> > On Thu, Aug 30, 2007 at 11:04:00AM -0400, Trond Myklebust wrote:
> >
> > > What I'm saying is that the superuser can pretty much do whatever it
> > > takes to grab either your kerberos password (e.g.
On Thu, 30 Aug 2007, J. Bruce Fields wrote:
> On Thu, Aug 30, 2007 at 11:04:00AM -0400, Trond Myklebust wrote:
> > With CIFS or other password based protocols (including RPCSEC_GSS)
>
> Well, rpcsec_gss isn't inherently password based, and you can
> authenticate in some way that doesn't actuall
On Thu, Aug 30, 2007 at 11:04:00AM -0400, Trond Myklebust wrote:
> With CIFS or other password based protocols (including RPCSEC_GSS)
Well, rpcsec_gss isn't inherently password based, and you can
authenticate in some way that doesn't actually give away your password
(or other long-lived credential
On Thu, Aug 30, 2007 at 04:42:33PM +0200, Jan Engelhardt wrote:
>
> On Aug 30 2007 10:29, Trond Myklebust wrote:
> >On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote:
> >>
> >> with NFS3, there is this 'root hole', i.e. any person who has a root
> >> account (perhaps by use of a laptop) ca
On Thu, 2007-08-30 at 16:42 +0200, Jan Engelhardt wrote:
> On Aug 30 2007 10:29, Trond Myklebust wrote:
> >On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote:
> >>
> >> with NFS3, there is this 'root hole', i.e. any person who has a root
> >> account (perhaps by use of a laptop) can mount an
On Aug 30 2007 10:29, Trond Myklebust wrote:
>On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote:
>>
>> with NFS3, there is this 'root hole', i.e. any person who has a root
>> account (perhaps by use of a laptop) can mount an export (let's say this
>> export had the "root_squash" option),
On Thu, 2007-08-30 at 10:29 -0400, Trond Myklebust wrote:
> We've got people working on fixing this problem using David Howells'
> keyrings, but it will probably be a while until we've solved all the
> upcall issues, and it will probably take even longer to push the
> kerberos changes back to the o
On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote:
> Hi,
>
>
> with NFS3, there is this 'root hole', i.e. any person who has a root
> account (perhaps by use of a laptop) can mount an export (let's say this
> export had the "root_squash" option), and still have a look at the user
> files
Hi,
with NFS3, there is this 'root hole', i.e. any person who has a root
account (perhaps by use of a laptop) can mount an export (let's say this
export had the "root_squash" option), and still have a look at the user
files, because he can locally setuid() into another user.
So I was looking
32 matches
Mail list logo
