If the user has the ability to read the page file - i.e. root - then he also has the ability to use the debugger to inspect the live memory as well - so as the OP pointed out - if root is compromised - nothing is secure.
> On Oct 15, 2018, at 4:36 PM, EricR <ad...@peppermind.com> wrote: > > If the memory in which the master key resides is not locked, then it may be > written to the page file. An attacker may thus boot the machine from an > external disk, mount the disk, read the page file, obtain the master key from > the page file, and then decrypt the password database. The attack requires > physical access but also works with a cloned disk, so the user need not even > realize it has happened. > > It's a standard attack. It's also not far-fetched to assume that an attacker > could create memory pressure, for example by running a trojan process as an > ordinary that uses as much available memory as possible, in order to ensure > the master key is paged to disk. > > Whether you want to safeguard against this scenario or not is another > question, it always depends on the threat model. I don't know how good this > memguard is, but if it does what it promises, then it would likely make the > application more secure. > > On Monday, October 15, 2018 at 9:18:18 PM UTC, robert engels wrote: > As long as the passwords are not stored in plain text in memory - meaning > they are only temporarily decoded in order to be provided (and then the > memory wiped) - there is no difference than the underlying security of the > file encryption on disk, no ? > > > On Oct 15, 2018, at 4:13 PM, Christopher Nielsen <m4dh...@ <>gmail.com > > <http://gmail.com/>> wrote: > > > > On Mon, Oct 15, 2018 at 1:28 PM Matthias Schmidt > > <matthias...@ <>gmail.com <http://gmail.com/>> wrote: > >> > >> Hi Eric, > >> > >> thanks *a lot* for your valuable feedback! I really appreciate it. See > >> comments inline: > >> > >> Am Montag, 15. Oktober 2018 12:09:32 UTC+2 schrieb EricR: > >>> > >>> Since you're looking for opinions on the security concept, two questions > >>> spring immediately to my mind: > >>> > >>> 1. Does the daemon keep the sensitive data in locked memory that cannot > >>> be paged out? If so, how cross-platform is this? > >> > >> > >> No it doesn't. As of now i consider the root-user a good guy ;-) > >> He's the only one who could access the pagefiles anyway. > >> > >> So is this really an issue? If yes i could use this cross-platform > >> solution to pin the key: > >> > >> https://github.com/awnumar/memguard <https://github.com/awnumar/memguard> > >> > >> > >>> > >>> > >>> 2. How does the client communicate securely with the daemon? Which > >>> encryption protocol/handshake is used for this? (If it just uses a > >>> socket, what would prevent another process from reading out the master > >>> password?) > >> > >> > >> It's in fact a unix domain socket file which is only accessible for the > >> owner of the key. ( Thanks for bringing this up, i forgot to flag the file > >> correctly - it's now fixed). > >> Relying on the file permissions in unix shouldn't be a problem, right? > >> > >> cheers & again - many thanks, > >> > >> Matthias > > > > You seem to be putting a lot of trust in facilities that are trivially > > exploitable to a determined attacker. For software like a password > > manager, assuming the kernel is secure is a poor security model. In > > addition to the existing attack surface, we live in a world where > > side-channel attacks are becoming more common, e.g., Spectre and > > Meltdown, so it isn't safe to assume the kernel or hardware are > > secure. A password manager needs to have a robust security model that > > has a minimal trust model if it is to be more than a toy. > > > > Just my $0.02 > > > > -- > > Christopher Nielsen > > "They who can give up essential liberty for temporary safety, deserve > > neither liberty nor safety." --Benjamin Franklin > > "The tree of liberty must be refreshed from time to time with the > > blood of patriots & tyrants." --Thomas Jefferson > > > > -- > > You received this message because you are subscribed to the Google Groups > > "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to golang-nuts...@ <>googlegroups.com <http://googlegroups.com/>. > > For more options, visit https://groups.google.com/d/optout > > <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
