Re: what's next for the linux kernel?

[Valdis.Kletnieks@vt.edu]

On Thu, 06 Oct 2005 00:03:09 BST, Luke Kenneth Casson Leighton said:
> On Wed, Oct 05, 2005 at 02:47:27PM -0400, Horst von Brand wrote:

> > Nope. SELinux provides MAC, 
> 
>  yes.
> 
> > i.e., mechanisms by which system-wide policy
> > (not the random owner of an object) ultimately decides what operations to
> > allow. 
> 
>  yes.  the concept is not incompatible with what i said: the only bit
>  that is wrong with what you've said is the word "Nope".
> 
> > That is not "file permissions". 
> 
>  part of the coverage of the MAC is file and directory permissions, and
>  as i mentioned earlier, it so happens that each selinux permission
>  corresponds, i believe one-to-one, with a function in the dnode and
>  inode vfs higher-order-function tables in the linux kernel.
> 
>  example permissions (from postfix.te, policy source version 18):
> 
> 	allow postfix_$1_t { sbin_t bin_t }:dir r_dir_perms;
> 	allow postfix_$1_t { bin_t usr_t }:lnk_file { getattr read };
> 	allow postfix_$1_t shell_exec_t:file rx_file_perms;
> 
>  i am confident enough with selinux to say that those are file
>  and directory permissions.

The part that you managed to miss is that this is MAC - *Mandatory*
Access Control.  This means that the *sysadmin* gets to say "this user
can't look at that file" - and there's nothing(*) either the owner of the
file or the user can do about it.  There's no chmod or chattr or chacl
command that the owner can issue to let somebody else read it - that's
the whole *point* of MAC.

(*) Well.. almost nothing.  The owner *may* be able to copy the contents
of the file to another file that the other user is allowed to read.  On the
other hand, the ability to do this would generally indicate a buggy policy....

Attachment: pgphfhOaBM1fV.pgp
Description: PGP signature