From: "U.Mutlu" <for-gmane@mutluit.com>
To: linux-ext4@vger.kernel.org
Subject: Re: generic question: user-only directory w/o root access
Date: Fri, 5 Jun 2015 21:24:51 +0200 [thread overview]
Message-ID: <mkst24$nbb$1@ger.gmane.org> (raw)
In-Reply-To: <20150605141429.GA26550@thunk.org>
Theodore Ts'o wrote on 06/05/2015 04:14 PM:
> On Thu, Jun 04, 2015 at 03:24:06PM +0200, U.Mutlu wrote:
>> 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.
>
> I wouldn't count out a sufficiently clever root user. At the very
> minimum, root could replace the kernel and wait for the system to
> reboot under normal circumstances. The root user could load a kernel
> module (or replace an existing kernel module) that gives him access to
> *any* namespace, or extract *any* key, or read from *any* userspace
> process.
>
> If there are any shared files used by both the container and rest of
> the system (i.e., if the container only contains the data files and
> uses /usr/bin and /bin and /lib from the rest of the system), then
> root could replace one of these executables or shared libaries which
> would then used by the container. If you are using kvm in the
> "secure" container, root could insert mailware into the kvm binary.
>
> If you are using a secure boot system (i.e., using UEFI bios with your
> own firmware public/private key pair), and then use a kernel signed by
> your BIOS key, and then use signed modules, and then use SELinux to
> try to add more fences to prevent unauthorized changes to binaries,
> you can make things more secure.
>
> But your original statement talked about trying to protect against all
> root users, and that's what was so concerning. Listing all of the
> authorized users may very well be a very large list. Consider that on
> a Debian system, this includes all of the people authorized to upload
> packages to the debian-security repository (or the equivalent for
> Fedora, SuSE, etc.)
>
> This is why a lot of people who hear words like "rock solid" will
> start assuming that the speaker either doesn't know what he or she is
> talking about, and/or is a snake oil salesperson. :-)
>
> Regards,
>
> - Ted
Dear Ted,
true, the dangers and challenges are high. The solution I finally
found took me unfortunately a long time to find it, and I know of
no other open-source solution to achieve what I described,
because of the unfortunate 'root is king and user is nobody' mentality
and reality we have.
But as described, in some security environments the user needs
a truly private space on the system where nobody else has access to.
I'm just a concerned admin seeking a practical solution to
the challenging problem IMO we all face nowadays regarding
data security and integrity.
If you have any other or further ideas on how such a security goal
could be realized or improved upon under a stock Linux distribution,
let me know pls, I'm open for all suggestions.
I think the filesystem could indeed implement such a "user-only" directory,
because the FUSE-API wrapper showed me that it is indeed possible
to implement that idea. I would suggest to add this feature to ext4,
and that new feature could be a real game-changer (yes, I know another
bold statement) in IT security.
Thx
Uenal
next prev parent reply other threads:[~2015-06-05 19:25 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
2015-06-04 13:24 ` U.Mutlu
2015-06-05 14:14 ` Theodore Ts'o
2015-06-05 19:24 ` U.Mutlu [this message]
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='mkst24$nbb$1@ger.gmane.org' \
--to=for-gmane@mutluit.com \
--cc=linux-ext4@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).