lkml.org 
[lkml]   [2007]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: New LSM security operation

> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-07-12 07:23    [W:0.059 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site