On Wed, Mar 05, 2014 at 16:15, Giancarlo Razzolini wrote:
Hi,
I have one linux server that has full disk encryption, and I use
it's initramfs with dropbear to be able to remote unlock the encrypted
root partition.
From what I read from the OpenBSD documentation, this is not
Em 05-03-2014 17:30, Ted Unangst escreveu:
On Wed, Mar 05, 2014 at 16:15, Giancarlo Razzolini wrote:
Hi,
I have one linux server that has full disk encryption, and I use
it's initramfs with dropbear to be able to remote unlock the encrypted
root partition.
From what I read from the
On 2014/03/05 17:48, Giancarlo Razzolini wrote:
Em 05-03-2014 17:30, Ted Unangst escreveu:
On Wed, Mar 05, 2014 at 16:15, Giancarlo Razzolini wrote:
Hi,
I have one linux server that has full disk encryption, and I use
it's initramfs with dropbear to be able to remote unlock the
Em 05-03-2014 18:05, Stuart Henderson escreveu:
On 2014/03/05 17:48, Giancarlo Razzolini wrote:
Em 05-03-2014 17:30, Ted Unangst escreveu:
On Wed, Mar 05, 2014 at 16:15, Giancarlo Razzolini wrote:
Hi,
I have one linux server that has full disk encryption, and I use
it's initramfs with
On Wed, Mar 05, 2014 at 06:11:35PM -0300, Giancarlo Razzolini wrote:
I'm not trying to protect anything. Physical access almost always
means game over. There could be some work on the area of trusted
booting, using TPM chips, but this is another beast entirely.
I'm trying to be
On Wed, Mar 05, 2014 at 06:36:55PM -0300, Giancarlo Razzolini wrote:
| One byproduct of such design would be the possibility of redirecting the
| console to the ssh connection. I know this is deranging from the initial
| idea, but make perfect sense. Anyway, I noted your concerns on this.
| Now,
Giancarlo Razzolini [grazzol...@gmail.com] wrote:
One byproduct of such design would be the possibility of redirecting the
console to the ssh connection. I know this is deranging from the initial
idea, but make perfect sense. Anyway, I noted your concerns on this.
Now, anyone have any design
On Wed, 5 Mar 2014, Stuart Henderson wrote:
What are you trying to protect against?
If somebody has physical access, they can presumably replace the
kernel/initramfs with a trojanned version ...
It protects against stolen machines, but not active attacks.
Our cryptoraid doesn't protect
On 2014/03/06 09:15, Damien Miller wrote:
On Wed, 5 Mar 2014, Stuart Henderson wrote:
What are you trying to protect against?
If somebody has physical access, they can presumably replace the
kernel/initramfs with a trojanned version ...
It protects against stolen machines, but not
previously on this list Giancarlo Razzolini contributed:
I prefer to have /etc and everything else
encrypted. If not, I would have to move lots of configuration files to
the encrypted partition, not to mention that it would very error prone.
You can always use symlinks or mount encrypted
previously on this list Kevin Chadwick contributed:
Though I can understand the FDE approach for Linux due to it's rather
and pointlessly (IMO) complex boot.
Obviously not all using the linux kernel like buildroot for embedded
which can be literally six lines of shell but probably every
Em 05-03-2014 19:03, Chris Cappuccio escreveu:
Personally I think this sort-of soft-IPMI is a pretty cool idea and I found
Matthieu's reply enlightening as well.
Apparently Linux has made some progress beyond pivot_root and there are
some interesting ideas there. (Note that we have a
On Wed, Mar 05, 2014 at 22:28, Giancarlo Razzolini wrote:
Rather than that, what about contribute with ideas for this. I believe
that it's not only FDE unlocking that would benefit of early network. As
I mentioned before, the possibility of redirecting the console to the
ssh session is one of
Em 05-03-2014 23:01, Ted Unangst escreveu:
If we're going to discuss things that would be useful, I have for
quite some time wanted a kexec() syscall that loads a new kernel and
reboots into it. I think that would be helpful for a variety of tasks,
not least of which is avoiding the four
But I believe, not have looked much at the code yet, that the kexec()
approach would be simpler than implementing the pivot_root().
Well, certainly less issues to deal with in C code. Instead you'll be
running up against debugging things relating to that file called
locore.S ...
Em 05-03-2014 23:17, Theo de Raadt escreveu:
But I believe, not have looked much at the code yet, that the kexec()
approach would be simpler than implementing the pivot_root().
Well, certainly less issues to deal with in C code. Instead you'll be
running up against debugging things relating
16 matches
Mail list logo
