linux-kernel - Re: [AppArmor 38/45] AppArmor: Module and LSM hooks

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: <200706130150.51140.agruen@suse.de>
Date:	Wed, 13 Jun 2007 01:50:50 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Stephen Smalley <sds@...ho.nsa.gov>
Cc:	Pavel Machek <pavel@....cz>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 38/45] AppArmor: Module and LSM hooks

On Monday 11 June 2007 16:33, Stephen Smalley wrote:
>>From a userland perspective, audit and inotify allow you to specify
> watches on pathnames, and those watches trigger actions by the audit and
> inotify subsystems when those files are accessed.  The kernel mechanism
> however is inode-based, not pathname-based; the pathname is merely
> looked up when the watch is added and mapped to an inode.  That's my
> point - why should AA be different?

Audit watches are not entirely object based (contrary to what the man page 
says): with simple file renames the watches sticks with the names; with 
directory renames, watches below the directory get dropped. That's rather 
weird, and I would say bad for audit.

Inotify really watches objects. I can imagine cases where this is exactly what 
you want, and others where this is exactly what you don't want -- it's pick 
your poison.

AppArmor deliberately is pathname based. There are good reasons for that, and 
we really, definitely want this pathname based model, with all its benefits 
and disadvantages. Arguing that AppArmor shouldn't be pathname based because 
other parts of the kernel try to balance names vs. objects differently, and 
not even always the same way either, is pretty narrow-minded.

If one thing is clear from this entire discussion, it is that there is no 
agreement on the One True Model, and different solutions are being used.

> Would you really recommend that audit or inotify call d_path() on each
> open and glob match the result against a list of audit or inotify watches?

I don't remember doing so.

Thanks,
Andreas
-
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/