public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: "Lukáš Czerner" <lczerner@redhat.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: "U.Mutlu" <for-gmane@mutluit.com>, linux-ext4@vger.kernel.org
Subject: Re: generic question: user-only directory w/o root access
Date: Thu, 4 Jun 2015 13:29:15 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1506041323280.32156@localhost.localdomain> (raw)
In-Reply-To: <20150604014452.GA5759@thunk.org>

On Wed, 3 Jun 2015, Theodore Ts'o wrote:

> Date: Wed, 3 Jun 2015 21:44:52 -0400
> From: Theodore Ts'o <tytso@mit.edu>
> To: U.Mutlu <for-gmane@mutluit.com>
> Cc: linux-ext4@vger.kernel.org
> Subject: Re: generic question: user-only directory w/o root access
> 
> On Mon, Jun 01, 2015 at 12:45:22AM +0200, U.Mutlu wrote:
> > A private directory (or private mountpoint) for the user only
> > (or for an application running under that 'user'-account).
> > 
> > The rationale behind this is: there are many system programs,
> > and other programs running with root rights. The user cannot know
> > them all and so cannot trust them. This includes also admins and the root
> > user itself.
> > 
> > The idea is to have a truly private directory or a private mountpoint
> > where by default nobody else has access to it, incl. root,
> > unless the owner grants access to others.
> 
> A user can't protect herself from root.  For one thing, root can
> modify the kernel, or install a module that runs arbitrary code inside
> the kernel context.  If you can insert or run arbitrary kernel code,
> you can do *anything*.  You can extract the user's encryption key; you
> can mess with arbitrary namespaces.  Root can use ptrace to muck with
> a running process.  Etc., etc., etc.
> 
> > So, my wish is to mount an encrypted virtual HD to a mountpoint,
> > and nobody else shall have access to it, especially not root or
> > any program with root rights.
> > 
> > Does anybody know of such an open-source solution for Linux?
> 
> No, just as there is no open-source solution for a perpetual motion
> machine...
> 
> Ultimately, the user has to trust the hardware and the firmware on it,
> the kernel, root, whoever is building the kernel (i.e., if you are
> using Debian and using the Debian kernel, you have to trust the people
> who build the Debian kernel, the Debian ftpmasters and so on).
> 
>     	      	     	     	 		   - Ted

Everything Ted mentioned is true. However there are ways to prevent
application and daemons running under root privileges doing harmful
things. Using Selinux is one of the ways
(https://en.wikipedia.org/wiki/Security-Enhanced_Linux).

However note that it'll still require you to trust your hardware,
kernel, whoever has a root access and to some extent the
applications as well because since it will protect you from someone
exploiting a bug in the application it will not fully protect you
from intentionally malicious application (because again, as a root
user you *can* do anything).

-Lukas

> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2015-06-04 11:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-31 16:07 generic question: user-only directory w/o root access U.Mutlu
2015-05-31 18:59 ` Theodore Ts'o
2015-05-31 22:45   ` U.Mutlu
2015-05-31 23:14     ` U.Mutlu
2015-06-01  1:39       ` Linux unshare -m for per-process private filesystem mount points U.Mutlu
2015-06-04  1:44     ` generic question: user-only directory w/o root access Theodore Ts'o
2015-06-04 11:29       ` Lukáš Czerner [this message]
2015-06-04 13:24         ` U.Mutlu
2015-06-05 14:14           ` Theodore Ts'o
2015-06-05 19:24             ` U.Mutlu
2015-06-06  0:33               ` Theodore Ts'o
2015-06-06  7:19                 ` U.Mutlu
2015-06-06 15:42                   ` Theodore Ts'o
2015-06-06 17:46                     ` U.Mutlu
2015-06-06 19:48                       ` Theodore Ts'o
2015-06-08  0:12                         ` U.Mutlu
2015-06-08  3:18                           ` Theodore Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.1506041323280.32156@localhost.localdomain \
    --to=lczerner@redhat.com \
    --cc=for-gmane@mutluit.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox