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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sat, 6 Jun 2015 19:46:14 +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

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.

--
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