On Wed, Oct 1, 2014 at 3:49 AM, Bill Horne wrote:
> On 9/30/2014 9:38 AM, Edward Ned Harvey (blu) wrote:
>>
>> In linux, I'm not aware of any product that does whole disk encryption
>> without needing a power-on password. In windows, Bitlocker uses the TPM to
>> ensure the OS gets booted untamper
> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss-
> bounces+blu=nedharvey@blu.org] On Behalf Of Bill Horne
>
> On 9/30/2014 9:38 AM, Edward Ned Harvey (blu) wrote:
> > In linux, I'm not aware of any product that does whole disk encryption
> without needing a power-on password.
On Wed, Oct 1, 2014 at 12:52 PM, Edward Ned Harvey (blu)
wrote:
>> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss-
>> bounces+blu=nedharvey@blu.org] On Behalf Of Bill Horne
>>
>> On 9/30/2014 9:38 AM, Edward Ned Harvey (blu) wrote:
>> > In linux, I'm not aware of any product t
> From: Bill Bogstad [mailto:bogs...@pobox.com]
>
> It seems like
> whenever people start talking about computer security, there is a
> tendency to shoot for the maximum theoretically possible. We don't do
> that when it comes to our cars or homes, but it does with computers.
Along a similar vei
Meh.
Today, if someone were to ask my opinion I'd say "no" to any and every
software-based disk encryption system. If you want to encrypt the entire
disk then get a self-encrypting disk and set a BIOS/firmware password on
the host.
--
Rich P.
___
Discu
Bill Ricker writes:
> Code fuzzed on the ENV value *after* the function definition should
> not have been accepted at all. Executing it at function def time is a
> bug.
What troubles me most about this is how the bit of code that reads in
environment variables sends the function body string into
On 9/30/2014 10:59 PM, Bill Ricker wrote:
>Code injection in a critical gut component like /bin/sh ...
> implemented with a link. Oops !
And Lennart wonders why some of us hate his code.
> Note that Multiple additional BASH security bugs have been found
> and/or fixed since they started look
On 10/1/2014 9:32 AM, Edward Ned Harvey (blu) wrote:
From: Bill Bogstad [mailto:bogs...@pobox.com]
It seems like whenever people start talking about computer security, there is a
tendency to shoot for the maximum theoretically possible. We don't do
that when it comes to our cars or homes, but
On Wed, Oct 1, 2014 at 4:56 PM, Richard Pieri wrote:
> Meh.
>
> Today, if someone were to ask my opinion I'd say "no" to any and every
> software-based disk encryption system. If you want to encrypt the entire
> disk then get a self-encrypting disk and set a BIOS/firmware password on
> the host.
Discussion on this topic has veered from the technical -- what's the state of
open-source or low-cost key-server and encryption software today -- to the
tactical: why bother?
I'll address the why-bother: I live in the heart of the tech capital of the
world, San Francisco. The city is seeing a sur
On 10/1/2014 11:19 AM, Bill Bogstad wrote:
> Because you trust the firmware provided by the disk drive manufacturer? You
> clearly aren't wearing your tin foil hat today.
The encryption in SEDs is good enough to keep someone who swipes a
notebook from getting at the data on it. They're strong ag
On 10/1/2014 12:06 PM, Rich Braun wrote:
> (a) the keys are convenient, readily accessible at every reboot
> (b) the keys can't readily fall into the wrong hands
These are contradictory requirements. The more readily accessible the
keys are, the more readily they can be obtained by unwanted actors
On Wed, Oct 1, 2014 at 11:07 AM, Richard Pieri wrote:
>> Note that Multiple additional BASH security bugs have been found
>> and/or fixed since they started looking harder in the last week.
> Which is not a bad thing as long as the people looking actually
> understand what they are looking at and
On 10/1/2014 12:34 PM, Bill Ricker wrote:
> Yes indeed. Unskeptical eyes are useless for security review no matter
> how multiplied.
As an aside, this is why I trust self-encrypting disk firmware. Rather,
it's better to say that I don't trust it any more or less than I trust
software like TrueCryp
On Tue, Sep 30, 2014 at 09:49:48PM -0400, Bill Horne wrote:
> On 9/30/2014 9:38 AM, Edward Ned Harvey (blu) wrote:
> >In linux, I'm not aware of any product that does whole disk
> >encryption without needing a power-on password. In windows,
> >Bitlocker uses the TPM to ensure the OS gets booted un
On 10/1/2014 12:06 PM, Rich Braun wrote:
Discussion on this topic has veered from the technical -- what's the state of
open-source or low-cost key-server and encryption software today -- to the
tactical: why bother?
As it must at some point: even if I were an FAA-certifiend Airframe and
Powerp
On Wed, Oct 01, 2014 at 01:41:43PM +0200, Bill Bogstad wrote:
> Unlike on-line data thieves who can automate their data collection
> to attack thousands, actually retrieving data from you stolen laptop
> will take significant human effort on their part.
Unless it doesn't. If the attacker knows yo
On 10/1/2014 2:38 PM, Bill Horne wrote:
>> (a) the keys are convenient, readily accessible at every reboot
>> (b) the keys can't readily fall into the wrong hands
>
> Fingerprint scanner.
A sharp knife will rectify that.
--
Rich P.
___
Discuss mailing
I'm *still* getting question as to why I want to encrypt my servers. There's
100,000+ photos on them. Email from the last 20 years. Brokerage account and
billing details. Typical of most anyone's server here. (I can hear the
voices saying: just put it in the cloud. Feh. I work in the cloud, t
I suggested possibly a talk on file systems, such as EXT, BTRFS, XFS,
and ZFS. Target this to users without getting overly technical.
Unfortunately I cannot be at the October meeting. Currently there is a
confusing set of elements for the users:
RHEL 7 is standardizing on XFS, Fedora 20 uses EXT4 a
Richard lives in a faraday cage :-)
The reasons I prefer software encryption is that algorithms can be
compromised. A software encryption system can be updated, and re-encrypt
your data. While firmware can also do the same thing it is more
difficult. Additionally you can set the BIOS/frmware passwo
On 10/1/2014 3:59 PM, Jerry Feldman wrote:
> Also, consider how valuable your data might be to a thief.
Rather, consider why, if the data is so valuable, you're storing it
where he can gain physical access to it.
--
Rich P.
___
Discuss mailing list
Dis
Richard Pieri wrote:
> There is a clever SED attack: hotplug. If you disconnect the SATA data
> cable without disconnecting power then you can plug the drive into a
> different host and the data will be readable. This is easily foiled
> simply by turning off the computer when physical security is l
Considering Rich Braun, he probably has a 2-bedroom apartment with both
bedrooms filled with computers, and he sleeps on a pull out couch in the
living room.
But, you are right on with that. Physical security is always the best
first option. But, for a regular person who essentially can't afford a
Bill Ricker wrote:
> Yes, it's a fair point that Gnu project is older than either Apache or
> Linux, but that doesn't exempt Bash from criticism.
>
> Alas there is both a mis-guided feature and at least one bug in the
> feature (even assuming its intent ever made any sense) -- as well as
> the en
On Wed, Oct 1, 2014 at 3:48 PM, Jerry Feldman wrote:
> I suggested possibly a talk on file systems, such as EXT, BTRFS, XFS,
> and ZFS. Target this to users without getting overly technical.
> ...> Another part of this would be RAID.
Great idea for topic, need a presenter who can boil it down.
On Wed, Oct 1, 2014 at 8:44 PM, Derek Martin wrote:
> On Wed, Oct 01, 2014 at 01:41:43PM +0200, Bill Bogstad wrote:
>> Unlike on-line data thieves who can automate their data collection
>> to attack thousands, actually retrieving data from you stolen laptop
>> will take significant human effort on
On Wed, Oct 1, 2014 at 4:59 PM, Tom Metro wrote:
> But in the case of CGI you are just moving the network/local
> barrier a bit further down the stack.
and moved it right through system() => /bin/sh => /bin/bash by alias
which last wasn't designed to be network secure.
> The CGI code is written
On Wed, Oct 1, 2014 at 4:59 PM, Tom Metro wrote:
>
> The age thing is a bit of a red herring, and that this came about due to
> a bug in Bash is almost irrelevant. The responsibility lies squarely
> with the application that provides the network interface. It should not
> be handing off unsaniti
Rich Braun wrote:
> (a) the keys are convenient, readily accessible at every reboot
> (b) the keys can't readily fall into the wrong hands
Is it a requirement that reboots happen unattended? If not, what level
of interaction is acceptable? You said in a previous message you didn't
want to have to
On Wed, Oct 1, 2014 at 6:08 PM, Richard Pieri wrote:
> On 10/1/2014 11:19 AM, Bill Bogstad wrote:
>> Because you trust the firmware provided by the disk drive manufacturer? You
>> clearly aren't wearing your tin foil hat today.
>...
>
> There is a clever SED attack: hotplug. If you disconnect th
Seems to me that changing the /bin/sh symlink to point to dash instead of
bash should ameliorate the problem, at least where scripts that invoke
/bin/sh don't depend on bash features.
Of course, finding all such sloppily-written scripts on an existing server
could be a big chore.
Once found, they
On Wed, Oct 1, 2014 at 5:34 PM, John Hall wrote:
> It also that shellshock would not apply to scripts in one language that
> use a subprocess for some functionality like a script in python or ruby
> that uses results from a perl or even a bash script, as long as any data
> that is passed went tho
Bill wrote:
> And we are back to what is your threat model and potentially
> "rubber hose" key retrieval.
> Or for that matter, if you have a "lot of money" do you have
> paper copies of your financial statements and if so do you keep
> them in a locked safe? And what about someone setting up a sp
On 10/1/2014 4:58 PM, Jerry Feldman wrote:
But, you are right on with that. Physical security is always the best
first option. But, for a regular person who essentially can't afford a
secure facility for his/her data, you've got to consider both encryption
and backing up to a secure backup locati
On 10/1/2014 5:48 PM, Bill Bogstad wrote:
Actually, they don't do everything that (open source) software
encryption does. They don't let you (or you an agent of your choice)
audit the encryption algorithms/implementation to verify that
everything is being done to spec.
True as far as your choic
Rich Pieri suggests:
> Or inside the box this time around: dog cages. A heavy duty, welded
> steel dog cage will run you $300-$500 depending on the size. Bolt the
> cage to the floor, put your server(s) in it, and lock it with a good
> padlock. Voila! your own secure data cage.
Thank you, Tom Metr
FWIW, when I first started playing with computers, and was very poor, I
used to take whatever my neighbors would discard on trash day and fix it
up. I found a some personal info. Of course I didn't abuse this, but
if it was encrypted it would have made me seeing it much harder. I
think hard
On 10/1/2014 8:27 PM, Rich Braun wrote:
So: the dog-cage idea.
Laugh if you want but I'm quite serious. I picked on dog cages because
they're strong and reasonably mobile until you remove the wheels and
bolt them down. Or chain to a couple of concrete blocks. Or embed in
concrete. Or whateve
On 9/30/2014 2:20 AM, Rich Braun wrote:
> The thorny problems with doing this are making sure that
>
> (a) the keys are convenient, readily accessible at every reboot
> (b) the keys can't readily fall into the wrong hands
> (c) infrequently-accessed filesystems aren't accessible except when needed
On 9/30/2014 2:20 AM, Rich Braun wrote:
> The thorny problems with doing this are making sure that
>
> (a) the keys are convenient, readily accessible at every reboot
> (b) the keys can't readily fall into the wrong hands
> (c) infrequently-accessed filesystems aren't accessible except when needed
On Wed, Oct 01, 2014 at 05:33:58PM -0400, Bill Ricker wrote:
> On Wed, Oct 1, 2014 at 4:59 PM, Tom Metro wrote:
> > But in the case of CGI you are just moving the network/local
> > barrier a bit further down the stack.
>
> and moved it right through system() => /bin/sh => /bin/bash by alias
> whi
I finally had the problem someone else had a little while back where
verizon's outgoing relay stopped working. Took a little fiddling to get
it working; I believe the OP in that thread was using postfix. If you
need to get sendmail going using a similar solution, check out the last
post in this t
43 matches
Mail list logo
