linux-ext4 - Re: generic question: user-only directory w/o root access

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150608031836.GA2842@thunk.org>
Date:	Sun, 7 Jun 2015 23:18:37 -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 08, 2015 at 02:12:38AM +0200, U.Mutlu wrote:
> 
> I could be wrong but I think the DENY_ATTACH is under the control
> of the running app itself.
> Not sure if any other process can change that on behalf of the app.

Nope, the kernel can do anything; and indeed, the DENY_ATTACH flag is
in the process's task_struct, and the kernel can modify any process's
task_struct.

> >And root can cause the kernel to lie to client applications.
>
> User or his app could check the hash of the kernel file to be sure
> it's still the official kernel.

The root user can load a kernel module without modifying the kernel
file.  There is also no way userspace can confirm that a particular
kernel file corresponds to the kernel file which is currently running.

What part of "root can do ***anything***" don't you understand?  There
are a few things that SELinux can do to control a random root process,
but the system administrator is still going to have enough power to
modify SELinux policies, and there is no way userspace can determine
whether or not the SELinux policies or the kernel is what it should
be.

There are a few ways you can control what kernel is running --- this
is why Microsoft is pushing UEFI, which can control things such that
the UEFI BIOS will only boot a kernel signed by Microsoft.  But you
really have to lock down the system, and ultimately you have to trust
whoever has access to the UEFI keys.  In your original problem
statement, you said you didn't want to trust the system administrator.
It's possible to set up a system using UEFI keys that will only boot a
digitally signed kernel -- but this still has to be set up by the
system administrator.  And if you purchase a Microsoft Surface device,
it will be locked down so it will only boot a Microsoft signed
operating system (and so you can't boot Linux at all, so a number of
folks don't consider UEFI to be an unalloyed feature).

						- Ted

P.S.  Before I started working on Linux as my vocation, in a previous
life I had over a decade's experience working on computer security
issues.  I was the Tech Lead on the MIT Kerberos v5 development team,
and the working group chair for the IP Security Working Group and a
member of the Security Area Directorate at the Internet Engineerint
Task Force, the standards body for the Internet.  So trust me, I
really do know what I am talking about.

You might also want to read Ken Thompson's (one of the fathers of
Unix) paper, Reflections on Trusting Trust:

https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

... and medidate deeply on what this means.  This shows what can
happen when the C compiler doesn't do what you think it will do.  The
fact that you assume the kernel will always do what it documented to
do, and that it can't be modified to do something different is
extremely naive.
--
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