linux-kernel - Re: [AppArmor 01/41] Pass struct vfsmount to the inode

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: <9d732d950705250101x13351c59y4afc4748aa73264b@mail.gmail.com>
Date:	Fri, 25 May 2007 17:01:20 +0900
From:	"Toshiharu Harada" <haradats@...il.com>
To:	"James Morris" <jmorris@...ei.org>
Cc:	"Andreas Gruenbacher" <agruen@...e.de>,
	"Al Viro" <viro@....linux.org.uk>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org,
	"Tony Jones" <tonyj@...e.de>
Subject: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

Hi,

2007/5/24, James Morris <jmorris@...ei.org>:
> I can restate my question and ask why you'd want a security policy like:
>
>  Subject 'sysadmin' has:
>     read access to /etc/shadow
>     read/write access to /views/sysadmin/etc/shadow
>
> where the objects referenced by the paths are identical and visible to the
> subject along both paths, in keeping with your description of "policy may
> allow access to some locations but not to others" ?

If I understand correctly, the original issue was whether to allow passing
vfsmount to the inode_create LSM hook or not. Which is independent from
AA or "pathname based MAC", I think.

It is proven that Linux can be used without that change,　however it is
also clear that current LSM cause the ambiguities as AA people has
explained. Clearing ambiguities is a obvious gain to Linux and will make
benefits for auditing besides "pathname based MAC".

So here's my opinion. If anybody can't explain clear reason (or needs)
to keep these ambiguities unsolved,　we should consider to merge
the proposal.

Thanks.

-- 
Toshiharu Harada
haradats@...il.com
-
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/