lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <mkpjhm$7i5$1@ger.gmane.org>
Date:	Thu, 4 Jun 2015 15:24:06 +0200
From:	"U.Mutlu" <for-gmane@...luit.com>
To:	linux-ext4@...r.kernel.org
Subject: Re: generic question: user-only directory w/o root access

Lukáš Czerner wrote on 06/04/2015 01:29 PM:
> On Wed, 3 Jun 2015, Theodore Ts'o wrote:
>
>> Date: Wed, 3 Jun 2015 21:44:52 -0400
>> From: Theodore Ts'o <tytso@....edu>
>> To: U.Mutlu <for-gmane@...luit.com>
>> Cc: linux-ext4@...r.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).

Hello Ted, Lukas, and All,

please don't get me wrong, I know how these things work.
My security concern is against possible trojans on the server
and online criminals using social engineering etc.

The said special security requirement is for a special high-security 
application. The customer files (encryped mails, cust db etc.)
has to be secured against online thiefs and for example against
NSA trojans maybe implanted thru "official" channels like is the
case with Adobe and Microsoft, everybody knows that...

I use a truecrypt container with ext2 on it and now use the mentioned
private namespace-mount, because only that single application (running
under its own user account) shall have access to the mountpoint,
root by default has no access to it, and yes as you both pointed out
root can overcome this, but then he would need to restart the machine.
But then he cannot mount the encrypted volume :-) [not using any automount],
so, imo that solution looks to me rock solid, and that was what I was
looking for when I started the thread here.

-- 
Thx
Uenal



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ