Re: Append vs. write distinctions

sdsat_private

> Does the LSM call to the permissions function specify the calling process?
> If so, can the SELinux module follow the reference to the calling process,
> and then inspect its security label, to determine whether this process is
> appropriately labeled for append access?

I guess I wasn't clear.  The issue is that the permission() function
only takes the read/write/execute flags, so the LSM permission() hook
that is called during the open system call cannot tell whether
the process only requested append access or whether the process requested
general write access.  

The existing Linux ext2 support for append-only files is merely file-based
- you set an append flag on the file, and all processes are limited to
append access to the file.  The append flag is set in the struct inode's
i_flags and various functions (including open_namei) check for this
flag using the IS_APPEND macro to ensure that only appends are permitted.
The IS_APPEND macro merely tests the inode flags - it isn't process-based.
If a security module sets the flag on an inode (e.g. in
the attach_pathlabel hook), then the restriction will be applied to
all processes that access the file represented by that inode.

SELinux provides an append permission separate from the write permission,
checking append permission if write access with O_APPEND was specified or
checking write permission if ordinary write access was requested.  Of
course, we also had to ensure that fcntl could not be used to clear
the O_APPEND flag if only append permission was granted.

Notice the distinction in semantics.  The SELinux append permission
is just like the write permission - it is checked between the process
and file, and it grants an access right to append to a file.  The existing
Linux support for append-only files is a flag - it is purely file-based,
and it limits all writes to a file to appending.  

Some possible solutions:

1) Change the computation of acc_mode in open_namei() to retain
the O_APPEND flag if it is in flags.  In the permission() function,
call the LSM permission security hook with this expanded access mode so
that it can distinguish append access from write access.  After calling
the LSM permission security hook, reduce the access mode to the
traditional read/write/execute modes before performing the normal
Linux checking (i.e. the call to the inode permission operation
or the call to vfs_permission).  OR

2) Change the IS_APPEND (and IS_IMMUTABLE and perhaps other) macros to
also call a LSM security hook when the check is performed so that the
security module has the option of performing a check at this point based
on both the process and the file.

--
Stephen D. Smalley, NAI Labs
ssmalleyat_private

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module