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
On Sun, May 31, 2015 at 06:07:38PM +0200, U.Mutlu wrote:
> 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?)?
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:
> On Sun, May 31, 2015 at 06:07:38PM +0200, U.Mutlu wrote:
>> 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?)?
>
> 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.
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:
> Theodore Ts'o wrote on 05/31/2015 08:59 PM:
>> On Sun, May 31, 2015 at 06:07:38PM +0200, U.Mutlu wrote:
>>> 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?)?
>>
>> 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.
>
> 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?
>
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
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
On Wed, 3 Jun 2015, Theodore Ts'o wrote:
> Date: Wed, 3 Jun 2015 21:44:52 -0400
> From: Theodore Ts'o <[email protected]>
> To: U.Mutlu <[email protected]>
> Cc: [email protected]
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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 <[email protected]>
>> To: U.Mutlu <[email protected]>
>> Cc: [email protected]
>> 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
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
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
On Fri, Jun 05, 2015 at 09:24:51PM +0200, U.Mutlu wrote:
> 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.
"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/
> 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.
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:
> On Fri, Jun 05, 2015 at 09:24:51PM +0200, U.Mutlu wrote:
>> 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.
>
> 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
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
On Sat, Jun 06, 2015 at 09:19:40AM +0200, U.Mutlu wrote:
> 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.
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:
> On Sat, Jun 06, 2015 at 09:19:40AM +0200, U.Mutlu wrote:
>> 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.
>
> So the root user ptraces the FUSE daemon, and it's all she wrote.
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.
On Sat, Jun 06, 2015 at 07:46:14PM +0200, U.Mutlu wrote:
> Theodore Ts'o wrote on 06/06/2015 05:42 PM:
> >On Sat, Jun 06, 2015 at 09:19:40AM +0200, U.Mutlu wrote:
> >>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.
> >
> >So the root user ptraces the FUSE daemon, and it's all she wrote.
>
> 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 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 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 root can cause the kernel to lie to client applications.
Next?
- Ted
Theodore Ts'o wrote on 06/06/2015 09:48 PM:
> On Sat, Jun 06, 2015 at 07:46:14PM +0200, U.Mutlu wrote:
>> Theodore Ts'o wrote on 06/06/2015 05:42 PM:
>>> On Sat, Jun 06, 2015 at 09:19:40AM +0200, U.Mutlu wrote:
>>>> 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.
>>>
>>> So the root user ptraces the FUSE daemon, and it's all she wrote.
>>
>> 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 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.)
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.
>> 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 root can cause the kernel to lie to client applications.
>
> Next?
User or his app could check the hash of the kernel file to be sure
it's still the official kernel.
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.