Re: New LSM security operation

From: Zeus Gómez Marmolejo
Date: Thu Jul 12 2007 - 01:21:40 EST



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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/