From owner-freebsd-questions@freebsd.org Tue Mar 8 08:23:23 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 8E626AC12C7 for ; Tue, 8 Mar 2016 08:23:23 +0000 (UTC) (envelope-from sergeig.public@gmail.com) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 48AC4BAE for ; Tue, 8 Mar 2016 08:23:23 +0000 (UTC) (envelope-from sergeig.public@gmail.com) Received: by mail-vk0-x22d.google.com with SMTP id e6so8484035vkh.2 for ; Tue, 08 Mar 2016 00:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PSp5V3B351XD8sMo8MhG3cO36NbL6+ccGRB0gxy7xl8=; b=Itx0O+xEgfzEedva/wsASm9ZN0n4jw2CgjESKWZJAkD65+H58b4gRykY2OGHsUGYfH K32y3PoY3RVSecSiQ84UiIjncq0lY6xLNiLeEawXbYcrrfI+Nq6lEePUgwn9dh/r78RT rHnNHdwBxIBaJu+zcuPpUT1UEl7NFEeHHnm4GdWXGbmrVgGA2x/eJOFyTt5ZEqjuss7M sH4sD+6OsdY0diZD80iSYUfmmdRC58fHnJqvXF3axr0KcQEbDR0olKqYGE61HhD17N99 CzYEGf+wBIjE9WfjHRcpfFwvm3zeF4a1ThSeQaNWnC6nnQOb7i+Rc42bW1NQpQoSnpRM jeGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PSp5V3B351XD8sMo8MhG3cO36NbL6+ccGRB0gxy7xl8=; b=HTgM2n0if/fuKOVMozv+Hi3CTSjSdt5seRtnPsTpXZ62knD8U790ASuTV8CWAot63x Px7dzJQqZEXbF5C6kTglojbOz041q68Clj066m+yH0KJ0upaqqD0g5bQNTHAyjknacgg fkJZVY1Z0DSE9XKSskPuEZjTDR1JQfJN5dHeFqDCkdCXyHi2fx5dXrNH/8zgX1/WQMtj rkiN3CXCTNJnevwvnhkaGMlcQQ3I3O9j0P5yw91n6fTg1R4Dy1OQJ8wTyreI3yOvx1nU P4O4RecqCVegL0s4vmoz3ZaIAu138ueplDOsrYNShc3LnQd7QQNZB/Q74Qx9dbrqx86I Wa1A== X-Gm-Message-State: AD7BkJJKZoEvf0B6Gceh93nOGyfS2YAfoXZue5nO7e57Fjn6q5YHWWFcRmsUTdaW5zbL5DeZTIWlVTRYhRsmvg== MIME-Version: 1.0 X-Received: by 10.31.6.130 with SMTP id 124mr20207334vkg.106.1457425402098; Tue, 08 Mar 2016 00:23:22 -0800 (PST) Received: by 10.31.174.132 with HTTP; Tue, 8 Mar 2016 00:23:21 -0800 (PST) In-Reply-To: <20160302215421.53c9a7be.freebsd@edvax.de> References: <20160302215421.53c9a7be.freebsd@edvax.de> Date: Tue, 8 Mar 2016 00:23:21 -0800 Message-ID: Subject: Re: is there a secure store associated with user? From: Sergei G To: Polytropon Cc: FreeBSD Questions Content-Type: text/plain; charset=UTF-8 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 08:23:23 -0000 My co-worker and I have discussed the issue of protecting sensitive data on Windows with DPAPI vs Linux world. 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. Thus, Windows OS has to store a form of user's password somewhere... (Windows AD security is excluded from this picture). 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. ... 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. 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. 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. Does it make any sense? Is it too much protection for the payoff? Does something like this exist today? This is not an active project for me, but it is an important issue to wrap my mind around. Thank you On Wed, Mar 2, 2016 at 12:54 PM, Polytropon wrote: > On Wed, 2 Mar 2016 10:45:10 -0800, Sergei G wrote: > > I am looking for FreeBSD (and Linux) equivalent of DP API in windows. For > > example, windows service has access to a secure data store associated > with > > user account. When I register service I enter service user id and > password > > and that password unlocks user store. > > This can be done using regular user:group permissions. Let's say > you run the service under a specific user "service" ; let's > furthermore say that Bob's user data is owned by bob:bob. Then > you just have to make user "service" a member of the group "bob" > and set the file attributes to rw-/r--/---, for example: user > can read and write, service can only read, nobody else can do > anything. > > In this case, the password of Bob doesn't even have to be known > to the service. Locking and unlocking is a matter of group > menbership. This is controlled by the system administrator. > > Oh, and an additional approach is using ACLs. Here, the user > himself can "unlock" things easily, if desired. > > There are probably many other ways that make such a way of access > control possible. > > > > > Is there something like that in Unix > > world? > > Yes, somehow. :-) > > > > -- > Polytropon > Magdeburg, Germany > Happy FreeBSD user since 4.0 > Andra moi ennepe, Mousa, ... >