linux-kernel - Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it unambiguous; exclude unreachable mount points from /proc/mounts

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]

Message-ID: <11570.213.222.28.155.1176791453.squirrel@webmail.xs4all.nl>
Date:	Tue, 17 Apr 2007 08:30:53 +0200 (CEST)
From:	"Rob Meijer" <capibara@...all.nl>
To:	"Alan Cox" <alan@...rguk.ukuu.org.uk>
Cc:	"Andreas Gruenbacher" <agruen@...e.de>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org,
	"Andrew Morton" <akpm@...ux-foundation.org>
Subject: Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it 
     unambiguous; exclude unreachable mount points from /proc/mounts

On Mon, April 16, 2007 23:57, Alan Cox wrote:
>> > That is a fairly significant and sudden change to the existing
>> > kernel/user interface.
>>
>> Well, this is not meant for 2.6.21. I hope it is possible to change it
>> in
>> early 2.6.22; otherwise if we can't fix mistakes from the past we are
>> pretty
>> doomed.
>
> I don't believe the existing behaviour _IS_ a mistake.
>
>> > This is untrue. The process can get there (via fd passing with another
>> > task)
>>
>> Process can access file descriptors which are unreachable via path name
>> just
>> fine indeed, but those fds still don't have a valid path in the context
>> of
>> that process.
>
> Which while problematic to your name based security is just fine to
> everything else.

The realisation that I feel needs to be made is that fd passing is a
legitimate transfer of authority, and attempting to block the usage of
this authority (or block the transfer of this authority) would be
extremely bad.

One thing however that does need some major attention is the amounth of
and the scope of the authority that is being transfered with directory
file handles.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/