Re: New LSM security operation

["Zeus Gómez Marmolejo" <zeus@aluzina.org>]

> Lets run a thought experiment on this notion...
>
> Let's say that the file you want to hide is "/etc/dangerous".
> One of your fellows decides to create a file for other purposes
> and decides to call it "/etc/dangerous", having looked in /etc
> and seeing no file with that name. What should happen when he
> calls open("/etc/dangerous", O_CREAT) :
>
>    1. a second /etc/dangerous is created
>    2. the open fails, returning EEXISTS
>    3. the open succeeds, silently replacing the old file
>
> Option 1 results in two files with the same name. True,
> AppArmor can handle this, but I think everyone else
> is going to have issues with it. Option 2 defeats the idea
> of the file being hidden. Option 3 is just bad.
>   
I don't see much problem on this. For me, the correct response is that 
one that just forget the "hidden" attribute, in that case if the user 
have the permission of overwritting the file, then the open succeeds, 
replacing the old file. In the other case, if the "list permission" and 
the "create permission" are denied the open fails. We can discuss in 
this case if with an EEXISTS or EACCES... Nevertheless I think it's a 
good idea, the same happens when a file is "read protected" and "list 
protected", and the user want to open the file for reading it. It could 
be: EACCESS or even ENOENT...

Just think about how useful would be in the /proc directory. For now, 
applying the selinux policy and doing "ls /proc", it reports errors on 
directories not owned by you because it cann't getattr() on them, but 
you can even know how many processes are running and even their pids. 
You have to apply an extra patch like Grsecurity to don't list the pids 
that are not owned by you in /proc. With this hook, this won't be 
necessary, just with a correct policy it can be done.


Zeus.