On Thu, 25 Aug 2011, da...@lang.hm wrote:
On Thu, 25 Aug 2011, berg...@merctech.com wrote:
In the message dated: Wed, 24 Aug 2011 20:44:37 PDT,
The pithy ruminations from da...@lang.hm on
were:
This scheme probably has more holes than a piece of Swiss cheese...but it
may
be better than th
In the message dated: Wed, 24 Aug 2011 20:44:37 PDT,
The pithy ruminations from da...@lang.hm on
were:
As will be abundantly clear in a few more words, I am not a crypto-expert...
=>
=> it only protects against the machine being stolen if the decryption key is
=> not also stored on the machin
On Thu, 25 Aug 2011, berg...@merctech.com wrote:
In the message dated: Wed, 24 Aug 2011 20:44:37 PDT,
The pithy ruminations from da...@lang.hm on
were:
As will be abundantly clear in a few more words, I am not a crypto-expert...
=>
=> it only protects against the machine being stolen if the d
On Wed, 24 Aug 2011, Paul Graydon wrote:
I try to reboot my database servers reasonably regularly as part of a
patching cycle, for example after applying kernel updates. Service uptime,
not server uptime :)
hear hear.
If they've got root on the system, they can presumably just restart MyS
On Wed, 24 Aug 2011, Singer X.J. Wang wrote:
How often do you reboot your database servers?
you better reboot them frequently or your system will be out of date and
vunerable to known secruity holes.
never mind the other unplanned type of reboot (datacenter wide power
outage due to a UPS b
It also protects if someone hacks into the system and gets root or the
server is physically stolen.
For that matter, I was always taught, and still always consider, that
physical access = no security. If they've got your disks, forget it.
Unless your system trashes the data after x failed
I try to reboot my database servers reasonably regularly as part of a
patching cycle, for example after applying kernel updates. Service
uptime, not server uptime :)
If they've got root on the system, they can presumably just restart
MySQL with skip-grant-tables and have direct access to the da
it only protects against the machine being stolen if the decryption key is
not also stored on the machine. This would mean that there needs to be a
manual step (either to enter the key or to unlock the key) every time the
machine boots. Since nobody does that (everyone wants the machine to boot
How often do you reboot your database servers?
It also protects if someone hacks into the system and gets root or the
server is physically stolen.
On Wed, Aug 24, 2011 at 23:44, wrote:
> it only protects against the machine being stolen if the decryption key is
> not also stored on the machine
Is it snake oil or is it not the solution for your problem? Just because its
not the solution to your problem does not mean its snake oil and from
reading your problem, it is not the solution for you.
This is the solution for people who has a box at SoftLayer or RackSpace, or
some VMs at Amazon EC
10 matches
Mail list logo
