linux-kernel - Re: r-o bind in nfsd

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: <57096.192.168.1.70.1206484328.squirrel@neil.brown.name>
Date:	Wed, 26 Mar 2008 09:32:08 +1100 (EST)
From:	"NeilBrown" <neilb@...e.de>
To:	"Tetsuo Handa" <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:	miklos@...redi.hu, viro@...iv.linux.org.uk, haveblue@...ibm.com,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, hch@...radead.org,
	linux-security-module@...r.kernel.org, jmorris@...ei.org
Subject: Re: r-o bind in nfsd

On Tue, March 25, 2008 10:45 pm, Tetsuo Handa wrote:
> Hello.
>
>> Maybe some enhancement to the 'intent' structure with a similar
>> effect could be done instead.
>>
>> Then you could, presumably, put a security hook somewhere in
>> link_path_walk for those modules (like AppArmor) which want to do
>> checks based on the namespace.
>
> I think link_path_walk() is not a good place to insert new LSM hooks
> for pathname based access control (AppArmor and TOMOYO) purpose because
>
>   (1) The kernel don't know what operation (open/create/truncate etc.)
> will be
>       done at the moment of link_path_walk().

Though the 'indent' data structure could be used to carry this information.

>
>   (2) Not all operations call link_path_walk() before these operations
>       are done. For example, ftruncate() doesn't call link_path_walk().

But do you want to impose path-name based controls to ftruncate?
Surely once you have a file open for write (not O_APPEND), then no
other permission is required to truncate the file, is it?
If it is, then maybe the 'struct file' should be tagged at open time
to say whether 'truncate' is allowed.

>
>   (3) The rename() and link() operations handle two pathnames.
>       But, it is not possible to know both pathnames at the moment of
>       link_path_walk().

Not an insolvable problem.
One could imagine an implementation where a TYPE_RENAME_FROM security
check produced a cookie that was consumed by a TYPE_RENAME_TO security
check.  The cookie could then be used by the security module to
make any connection between the two names that might be appropriate.

>
> I think we need to introduce new LSM hooks outside link_path_walk().
> http://kerneltrap.org/mailarchive/linux-fsdevel/2008/2/17/882024
>
<rant>
I suspect we would be much better off removing all the security hooks.
Security done at that level seems to be way too complex such that most
people don't really understand it.  And people who don't understand
security don't use it.
We'd be much better off getting rid of the whole "micro-manage security"
concept and provide isolation via some sort of high level container
approach.
</rant>

NeilBrown

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