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

Hello,
how can a non-root user have a directory of his own, without any root access? Is this somehow possible, or will it be made possible with the new ext4 (ext5?)?

Thx
Uenal

You're not going a lot of details about exactly what the use case you have in mind; are you talking about a non-root user creating a file system which then gets mounted somwhere? In practice you still need root to do the mount, or at the very least to set up the /etc/fstab to allow a non-root user to mount a file system at a particular mount point.

If it's the latter which you are envisioning, then the root_owner extended option to mke2fs(8) may be what you're looking for.

If it isn't please go into a much greater detail about what exactly it is you are trying to do, and why.

Regards,

- Ted

Theodore Ts'o wrote on 05/31/2015 08:59 PM:

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.

Ideal would be if the content therein were encrypted, as is planned for the upcoming new ext4-version.

With such a mechanism high-security applications could be realisied.

It seems with FUSE this is possible, but I have yet to find an encrypted filesystem that gives the above mentioned security. Truecrypt does not give that security as it itself needs and operates with root rights. I don't understand what the TC-programmers have done, because they seem not to have understood what FUSE is and can. They wrote their own cr*p around it instead of using the FUSE-interface, thereby totally _eliminating_ the good security mechanism FUSE offers by default.

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?

Thx
Uenal

U.Mutlu wrote on 06/01/2015 12:45 AM:

Here's a sample FUSE source code (user-land) which demonstrates the above said security scheme:

/* hello.c

FUSE: Filesystem in Userspace
Copyright (C) 2001-2007 Miklos Szeredi <[email protected]>

This program can be distributed under the terms of the GNU GPL. See the file COPYING.

Note by U.Mutlu:
this is a sample (hello.c) from the FUSE source distribution I modified it with my test code.

Compile:
gcc -Wall -o hello hello.c pkg-config fuse --cflags --libs

Mounting as user:
compile, s.a.

  $ mkdir mnt
  $ ./hello mnt
  $ ls -l mnt

root trying to access the mountpoint:
in a second window try to access the mountpoint as root --> it will deny
access to root, which is good:

  # ls -l
  ...
  d????????? ? ?      ?          ?            ? mnt
  ...

  # ls -l mnt
  ls: cannot access mnt: Permission denied

Unmounting:

  $ fusermount -u ./mnt

*/

#define FUSE_USE_VERSION 26

#include <fuse.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>

static const char* hello_str = "Hello World!\n";
static const char* hello_path = "/hello.txt";

static const char* uenal_str = "hi there\n";
static const char* uenal_path = "/uenal.txt";

static int hello_getattr(const char *path, struct stat *stbuf)

{
        memset(stbuf, 0, sizeof(struct stat));
        if (strcmp(path, "/") == 0)
        {
                stbuf->st_mode = S_IFDIR | 0755;
                stbuf->st_nlink = 2;
                return 0;
        }

        if (strcmp(path, hello_path) == 0)
        {
                stbuf->st_mode = S_IFREG | 0444;
                stbuf->st_nlink = 1;
                stbuf->st_size = strlen(hello_str);
                return 0;
        }

        if (strcmp(path, uenal_path) == 0)
        {
                stbuf->st_mode = S_IFREG | 0444;
                stbuf->st_nlink = 1;
                stbuf->st_size = strlen(uenal_str);
                return 0;
        }

        return -ENOENT;
}

static int hello_readdir(const char *path, void *buf, fuse_fill_dir_t filler, off_t offset, struct fuse_file_info *fi)

{
        (void) offset;
        (void) fi;

        if (strcmp(path, "/") != 0) return -ENOENT;

        filler(buf, ".", NULL, 0);
        filler(buf, "..", NULL, 0);

        filler(buf, hello_path + 1, NULL, 0);    // +1 um '/' zu skippen, 

s.o.; ...

        filler(buf, uenal_path + 1, NULL, 0);

        return 0;
}

static int hello_open(const char *path, struct fuse_file_info *fi)

{
     // if (strcmp(path, hello_path) != 0) return -ENOENT;

        if ((fi->flags & 3) != O_RDONLY) return -EACCES;

        return 0;
}

static int hello_read(const char *path, char *buf, size_t size, off_t offset, struct fuse_file_info *fi)

{
        (void) fi;

        if (strcmp(path, hello_path) == 0)
          {
            const size_t len = strlen(hello_str);
            if (offset < len)
              {
                if ((offset + size) > len) size = len - offset;
                memcpy(buf, hello_str + offset, size);
              }
            else
              size = 0;
            return size;
          }

        if (strcmp(path, uenal_path) == 0)
          {
            const size_t len = strlen(uenal_str);
            if (offset < len)
              {
                if ((offset + size) > len) size = len - offset;
                memcpy(buf, uenal_str + offset, size);
              }
            else
              size = 0;
            return size;
          }

        return -ENOENT;
}

static struct fuse_operations hello_oper =
{

        .getattr        = hello_getattr,
        .readdir        = hello_readdir,
        .open           = hello_open,
        .read           = hello_read,

};

int main(int argc, char *argv[])

{
        return fuse_main(argc, argv, &hello_oper, NULL);
}

I just found a cool linux feature which helps me to create private mounts where no other user or process can see or access it:
by using linux namespaces with the tool "unshare" from the pkg linux-utils.

It allows, besides other things, per-process private filesystem mount points. It also works with truecrypt-mounts.

Here's a good basic demo of the idea:
http://blog.endpoint.com/2012/01/linux-unshare-m-for-per-process-private.html

See also: man unshare, man 2 unshare

cu
Uenal

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.

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

Lukáš Czerner wrote on 06/04/2015 01:29 PM:

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Theodore Ts'o wrote on 06/05/2015 04:14 PM:

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

"where nobody else has access" is impossible on a shared system. Period. There reason why there is no other open-source solution is because there *is* no open source solution, period. You can't have an open source solution that perfromances something which is by definition impossible.

If someone needs truly private space, the only thing they can do is to use their own hardware, purcahsed at a computer store, and then to use a system like Tails[1] booted from a read-only USB stick.

[1] https://tails.boum.org/

... and even then they have to trust the people who implemented the Tails system, and the people who implemented the firmware on the computer system, and if the system was shipped to you, you have to trust that the NSA hasn't intercepted the hardware and compromised the hardware.

[2] http://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/

Sorry, I'm not willing to advertise that a file system has a feature which is a pure snake oil --- someone claiming that this can be done is making a fradulently untrue statement.

Regards,

- Ted

Theodore Ts'o wrote on 06/06/2015 02:33 AM:

I posted hello.c (a FUSE demo) in this thread. It is IMO even more secure than the private namespace mount method. The simple reason is:
because granting access to the volume (or to a single dir/file) is done inside that user-code itself, ie. the user/owner controls whom he actually gives access.
I'm sorry to say this, but this simply proves your last statement above wrong.

Thx for this interessting discussion and exchange of ideas on security Uenal

So the root user ptraces the FUSE daemon, and it's all she wrote.

- Ted

Theodore Ts'o wrote on 06/06/2015 05:42 PM:

Protection against tracing and debugging:
inside the user-application ie. here the FUSE-client, and also inside the FUSE daemon:

  ptrace(PT_DENY_ATTACH, 0, 0, 0);

Of course one would need to recompile the FUSE daemon. The company can enforce such a security policy.

And while we are at it, I would add a new option to the FUSE daemon, so that the client-app can query it before issuing the mount call, whether it has that protection built in or not, and proceed accordingly... IMO a solvable problem.

And so the root user can install a kernel module which toggles the PT_DENY_ATTACH flag for the FUSE daemon after it's started. Or it could use a kprobe or jprobe to dynamically patch the ptrace system call to cause it to disregard that flag. (Or use the ksplice funcionality which would make life even easier.)

And root can cause the kernel to lie to client applications.

Next?

- Ted

Theodore Ts'o wrote on 06/06/2015 09:48 PM:

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.

User or his app could check the hash of the kernel file to be sure it's still the official kernel.

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.

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.