Re: SELinux metadata protection

From: Serge E. Hallyn (serue@private)
Date: Sun Jan 01 2006 - 11:27:07 PST


Quoting KaiGai Kohei (kaigai@private):
> Hello,
> 
> Nowaday, I'm considering about a philosophical theme.
> 
> In my understanding, file-metadata includes _filename_ similar to filesize,
> update-timestamp, and so on. Most of permissions for reading metadata are
> defined as 'getattr' in SELinux.
> But permission for reading filename is defined as 'read' of parent directory,
> 'getattr' of each child-entries are not evaluated.
> 
> It seems a bit curious behavior for me. Why can an unauthorized process
> be allowed to know whether the file exists or not ?
> I think it's worthwhile to conceal the existence of files from unauthorized
> processes.
> 
> This patch enables to conceal the unauthorized files.
> [1/2] LSM_metadata_protection_v1.patch
>  - add security_file_readdir(), it's called when readdir() write each filename
>    to userspace.
>  - add security_inode_lookup(), it's called when filename is resolved by path_walk().
> 
> [2/2] SELinux_metadata_protection_v1.patch
>  - add checking 'getattr' permission on file_readdirand inode_lookup hooks.
> 
> Thanks, any comments please, and have a good year :)

Hmm, a question on behavior.

Let's say hallyn_t is allowed to write /var (var_t), but not to do
getattr on /var/secret_process_is_running (secret_t).  If hallyn_t
does ls /var/secret_process_is_running, he gets -ENOENT, but what
should he get if he does 'touch /var/secret_process_is_running'?
-EPERM obviously leaks information...

-serge



This archive was generated by hypermail 2.1.3 : Sun Jan 01 2006 - 18:29:33 PST