Hi, everyone.
Jeff Schiller was to be the speaker for the October BLU meeting, but he had
a scheduling conflict, and we had to reschedule him for November.
Can anyone recommend a new speaker and topic for October?
Thanks!
--
John Abreau / Executive Director, Boston Linux Unix
Email:
On Wed, Oct 1, 2014 at 3:49 AM, Bill Horne b...@horne.net 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
On Wed, Oct 1, 2014 at 12:52 PM, Edward Ned Harvey (blu)
b...@nedharvey.com 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
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 vein -
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.
___
Bill Ricker bill.n1...@gmail.com 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
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 looking
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 richard.pi...@gmail.com 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
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
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
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 richard.pi...@gmail.com 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
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 TrueCrypt
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
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
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 you
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 list
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,
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
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
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
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
On Wed, Oct 1, 2014 at 3:48 PM, Jerry Feldman g...@blu.org 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
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 richard.pi...@gmail.com 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
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 johnhall...@gmail.com 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
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 spy
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
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
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
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 tmetro+...@gmail.com 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
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
36 matches
Mail list logo
