This new acc_mode flag is just to tell the security system this inode
permission check is from the access system call. The security system can
use this information as it finds appropriete. In particular SELinux plans to
use this flag to alter what we choose to audit and what we do not choose to
audit.
Signed-off-by: Eric Paris <[email protected]>
---
fs/open.c | 2 +-
include/linux/fs.h | 5 +++++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/fs/open.c b/fs/open.c
index 1940498..ad9e17f 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -495,7 +495,7 @@ SYSCALL_DEFINE3(faccessat, int, dfd, const char __user *, filename, int, mode)
goto out_path_release;
}
- res = inode_permission(inode, mode | MAY_ACCESS);
+ res = inode_permission(inode, mode | MAY_ACCESS | FROM_ACCESS);
/* SuS v2 requires we report a read only fs too */
if (res || !(mode & S_IWOTH) || special_file(inode->i_mode))
goto out_path_release;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 5df69f0..7ff00dc 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -60,6 +60,11 @@ struct inodes_stat_t {
*/
#define MAY_ACCESS 16
#define MAY_OPEN 32
+/*
+ * This flag is only set in the access() and accessat() syscalls and can
+ * be used by the security system as it deems reasonable.
+ */
+#define FROM_ACCESS 64
/*
* flags in file.f_mode. Note that FMODE_READ and FMODE_WRITE must correspond
Eric Paris wrote:
> This new acc_mode flag is just to tell the security system this
> inode permission check is from the access system call. The security
> system can use this information as it finds appropriete. In
> particular SELinux plans to use this flag to alter what we choose to
> audit and what we do not choose to audit.
Does "as it finds appropriate" mean robust applications should try an
operation anyway even if access() says no from now on?
Btw, since you're looking at access(), the kernel could do with
euidaccess() or a flag ACCESS_EUID. (Either would be trivial to implement).
Glibc provides eaccess/euidaccess functions, but they work by calling
stat() and checking the mode bits when euid != ruid || egid != rgid,
which is clearly not very nice with ACLs, and perhaps not ideal for
SELinux's auditing of access calls either.
-- Jamie
On Sun, Sep 20, 2009 at 09:30:48PM -0400, Eric Paris wrote:
> This new acc_mode flag is just to tell the security system this inode
> permission check is from the access system call. The security system can
> use this information as it finds appropriete. In particular SELinux plans to
> use this flag to alter what we choose to audit and what we do not choose to
> audit.
I think you're better off splitting the existing MAY_ACCESS flag and
only using MAY_ACCESS for calles from access() insteaf of introducing
a FROM_ACCESS flag and causing lots of naming confusion.
On Tue, 2009-09-22 at 09:56 -0400, Christoph Hellwig wrote:
> On Sun, Sep 20, 2009 at 09:30:48PM -0400, Eric Paris wrote:
> > This new acc_mode flag is just to tell the security system this inode
> > permission check is from the access system call. The security system can
> > use this information as it finds appropriete. In particular SELinux plans to
> > use this flag to alter what we choose to audit and what we do not choose to
> > audit.
>
> I think you're better off splitting the existing MAY_ACCESS flag and
> only using MAY_ACCESS for calles from access() insteaf of introducing
> a FROM_ACCESS flag and causing lots of naming confusion.
What would you think of a new, MUST_REVALIDATE_PERMS which will do what
MAY_ACCESS does today. MAY_ACCESS would be just for access(2) and would
be the flag that I use for SELinux?
-Eric
On Tue, Sep 22, 2009 at 01:28:46PM -0400, Eric Paris wrote:
> > only using MAY_ACCESS for calles from access() insteaf of introducing
> > a FROM_ACCESS flag and causing lots of naming confusion.
>
> What would you think of a new, MUST_REVALIDATE_PERMS which will do what
> MAY_ACCESS does today. MAY_ACCESS would be just for access(2) and would
> be the flag that I use for SELinux?
Yeah, something like this. I don't like the MUST_REVALIDATE_PERMS name
too much, but unless someone comes up with a better one I can live with
it.
Christoph Hellwig wrote:
> On Tue, Sep 22, 2009 at 01:28:46PM -0400, Eric Paris wrote:
> > > only using MAY_ACCESS for calles from access() insteaf of introducing
> > > a FROM_ACCESS flag and causing lots of naming confusion.
> >
> > What would you think of a new, MUST_REVALIDATE_PERMS which will do what
> > MAY_ACCESS does today. MAY_ACCESS would be just for access(2) and would
> > be the flag that I use for SELinux?
>
> Yeah, something like this. I don't like the MUST_REVALIDATE_PERMS name
> too much, but unless someone comes up with a better one I can live with
> it.
MAY_ACCESS is used in only these places:
- access/faccessat
- chdir/fchdir
- chroot
And it is checked in only two easy to change places: nfs/dir.c and
fuse/dir.c.
Therefore how about MAY_CHDIR.
-- Jamie