From owner-freebsd-questions@freebsd.org Tue Mar 8 17:30:22 2016 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EB26AC7DE3 for ; Tue, 8 Mar 2016 17:30:22 +0000 (UTC) (envelope-from thelostadmin@gmail.com) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9BF81303 for ; Tue, 8 Mar 2016 17:30:21 +0000 (UTC) (envelope-from thelostadmin@gmail.com) Received: by mail-ig0-x22c.google.com with SMTP id ig19so57251201igb.0 for ; Tue, 08 Mar 2016 09:30:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=SPXuviSSJD2UNVtVMSrXRJSlZgRTbNOsCkv1WumT4Bs=; b=lHAJ9bUYLJglDKg78navzAPD3HMGNwYXakfoO0azvtBPuHyB6sgZYrF9WRuA+HOEY/ i5yfqIJHXA0dncWv+koZ7WNDQHmyfxwn3/Ty9K9d+kDJhYoZ78wVUpHdGQJL5wqrw3R7 btMBux9hDx/kyCHiHNSHA8CwaJ0AH95Rkg5Nzqsmpox+aaoWGHGVby1kXTY5J4qTujH7 oxJoOFjgvraoMzheVEdQUOSq48Vl09E/lqJMXNvy55SvTJfp8ExFS4jedGS/XDmSELKe fIjFuT3EZh7h2Onm+hnoxO/wBZ3qTzX9sUQrnktFTWIj4XIkBazhDa86C5+mfhDYnLMO ZrCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=SPXuviSSJD2UNVtVMSrXRJSlZgRTbNOsCkv1WumT4Bs=; b=Bht0jPsvHkdPKLZQLuP7zNEl0sivMEMy5F0pTw5Eh5r8loAzlxPpRzaWxJKs6Emhe3 haqbqzE1Im6TGJk3dBWqDYsq97ckaAiSFNXj6eG0erwewFYARmD1l2RskbPo0Vt2JcUE UCBKBjkDAtmiQVMQhrKYRyX+ZhYMWeEvmIoStrUfYWuzds9FBtrJnzNq7FT5tgC9DPCS Z+bgZuKj8bhIitjQSC7TwSzCR40pQE3i/HacYTsY5360i1FepPq7jtbIf0mWxG+xhR+r YRV2yxNV7fCRA1YtSPEZNywTP3W00KGUfUbYXUmWc1v5M/ha0SzVuwk74fnKU9yb+9pT QIkg== X-Gm-Message-State: AD7BkJJi+ClQuQzK016dLNLh6LPUR3CmycW1qv8SrR9cxGG2nn/lvknzXm7eg6V2+V7iOg== X-Received: by 10.50.43.134 with SMTP id w6mr18623495igl.22.1457458219760; Tue, 08 Mar 2016 09:30:19 -0800 (PST) Received: from imac.suntrap.ca ([45.72.133.64]) by smtp.gmail.com with ESMTPSA id 65sm657667ioq.43.2016.03.08.09.30.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2016 09:30:19 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: is there a secure store associated with user? From: The Lost Admin In-Reply-To: <20160308101535.d191de76.freebsd@edvax.de> Date: Tue, 8 Mar 2016 12:30:17 -0500 Cc: Sergei G , "freebsd-questions@freebsd.org" Message-Id: References: <20160302215421.53c9a7be.freebsd@edvax.de> <20160308101535.d191de76.freebsd@edvax.de> To: Polytropon X-Mailer: Apple Mail (2.3112) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 17:30:22 -0000 > On Mar 8, 2016, at 4:15 AM, Polytropon wrote: >=20 > First of all, thanks for describing your requirements more precisely. > As it seems, using standard permissions or ACLs is not going to work > for you. But allow me to throw in some further thoughts. >=20 > On Tue, 8 Mar 2016 00:23:21 -0800, Sergei G wrote: >> MS DPAPI is secure, because it relies on user's password to encrypt = user's >> data store. However, when windows services are involved, windows = service >> control manager (SCM) needs to store user's password, so it can = unlock >> DPAPI store when it starts the service. >=20 > This somehow invalidates your first sentence. Is the password known > to the service in plain text? Is it _stored_ in plain text? Or does > the service store something like a hash or somehow encrypted password, > and just checks "crypted vs. crypted" instead of "plain vs. plain" > after decrypt? >=20 > I won't go into detail about my feelings considering the idea that > a closed source product licensed from an NSA strategic partner can > be regarded "secure" - forgive my tinfoilhatness. ;-) >=20 MS DPAPI uses a variation on the PBKDF2 key generation algorithm = (https://msdn.microsoft.com/en-CA/library/ms995355.aspx) to generate a = key-encrypting-key for the user. The PBKDF2 uses the end-user=E2=80=99s = plain text password as a starting point along with a magic number from = the server itself. This key-encrypting-key is used to encrypt the data = encrypting key for storage on the server. When you use MS DPAPI in conjunction with a service that starts = automatically, the Data Encrypting Key is encrypted using a key unique = to the server that the service runs on. The exact nature and protection = around that key-encrypting-key depends on the hardware capabilities of = the server. It will use the Intel TPM, if available but can be = configured to not use. MS Windows (the Operating system) is built to protect the KEK from all = users, including administrators. It might be possible for a skilled = malicious hacker to bypass the OS protections and read the key directly = from RAM but if the Intel TPM is used for the system master-key storage, = it should not be possible to extract the data encrypting key from a disk = image or stolen hard disk. There are actually more layers of keys than I am describing above but it = gives you an idea. >=20 >=20 >> Thus, Windows OS has to store a >> form of user's password somewhere... >=20 > Exactly - this is one entity knowing the "keys to the kingdom" you > cannot trust. There are good and bad ways how to deal with passwords. > The best way is to not store them at all, the worst way is to store > them in plaintext. >=20 >=20 >=20 >> Our goal is to apply defense in depth and in this case it is a = protection >> of CONTENT of a file in case it was downloaded by an attacker. = Standard >> ACL solution does not work, because www user by definition has access = to a >> file's content to be able to work with (load it into application = memory). >> The file is not meant to be served, but it may be serviced due to a >> vulnerability or misconfiguration. That's the scenario that we are >> defending against. >=20 > Now I understand. You'd still encounter the problem that an attacker > will retrieve the data at a stage where it is _not_ encrypted, and > there definitely is such a stage, i.e., when the data is going to > be used (read or written). >=20 > I have something in mind which might not be a solution for you, but > could help develop further ideas: >=20 > Imagine the data is stored in a disk image. This image is encrypted, > so if the attacker gets the image, it's of no value. This image is > being mounted (read only or read/write, as needed) and decrypted > "through" a trusted "access layer". Modifications can only happen > at that time. After use, the image is unmounted and therefore > encrypted again. I'm obviously talking about a file system image > plus some kind of PGP layer. I think it is possible to implement > this with "SSH + NFS", or somehow "mount + PGP"=E2=80=A6 You might want to have a look at fuse and encfs. The key management for = encfs sucks but fuse has the advantage of working in user space. So, = only the user that actually mounted the filesystem with fuse can see the = mount point (by default). I found a fuse filesystem that uses gpg for file management but it was = written entirely in python which seams to defeat the purpose to me for = many reason. I would say you need something that supports a key server to properly = protect the encryption keys. I have tested the scenario where I use encfs to encrypt/decrypt files on = one server with the files themselves stored on an NFS share mounted from = a different server. I.e. Server A runs encfs and acts as a NFS client. = Server B is an NFS server and does not have the encryption keys. I = wouldn=E2=80=99t call this true defence in depth since an attacker can = trivially gain the encryption key if they get root (or the right user) = privileges on server A). To make the above more secure, a key server and modifications to key = management for encfs would be needed. >=20 >> One solution could be the deployment of a "security service" = providing data >> over a Unix file socket. The "security service" simply returns = password to >> the application and application decrypts sensitive data on the fly or = uses >> this password to establish DB connection. A direct download of file's >> content would not result in sensitive data exposure. >=20 > That would be possible, but again involves the knowledge of the > password (plain?) to possibly untrusted instances. >=20 >=20 >=20 >> The compromise is only possible if attacker gains ability to execute >> arbitrary code as www user and instructs system to connect to = "security >> service". The same is true to DPAPI protection. If attacker can = execute >> arbitrary code as a service user, then he or she can return = originally >> protected data in plain text form. >=20 > Being able to execute untrusted code basically is GAME OVER, > especially when running with non-trivial system privilege. > It would require that the associated user (corresponding to > the service) is only allowed to execute _one_ verified binary > image. >=20 >=20 >=20 >> In some way this is similar to WSC-DPAPI at the conceptual level. = WSC >> knows the user's password, unlocks user's store and starts = application with >> user's context. This "security service" plays a similar 3rd party = role of >> knowing the password and returning it. Unfortunately, some form of >> application ACL is necessary in this case. >=20 > Again, too much "know the password" is involved here. But maybe > this is inevitable for the setting you're describing. In that > case, it would sound possible to implement something like this > in Linux or UNIX. I don't know of a particular program which > does this, but I'd say it's more or less trivial: When access > to a file is requested which is under "user password control", > the service decrypts the file (knowing the required password), > and upon close(), re-encrypts it again. >=20 >=20 >=20 >> Does it make any sense? Is it too much protection for the payoff? >=20 > It's an additional means of security, but no "one size cures > all" approach. Just given the password is "password", "12345", > or "correcthorsebatterystaple", a quick dictionary-based attack > on an extracted encrypted file will reveal the content - and > will confirm that this password is valid for _other_ files > associated with that user... >=20 >=20 >=20 >> Does something like this exist today? >=20 > Not that I'm aware of, but still possible. >=20 >=20 >=20 >=20 > --=20 > Polytropon > Magdeburg, Germany > Happy FreeBSD user since 4.0 > Andra moi ennepe, Mousa, ... > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to = "freebsd-questions-unsubscribe@freebsd.org=E2=80=9D The Lost Admin thelostadmin@gmail.com