linux-kernel - Re: New LSM security operation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Thu, 12 Jul 2007 07:21:22 +0200
From:	Zeus Gómez Marmolejo <zeus@...zina.org>
To:	casey@...aufler-ca.com
CC:	linux-kernel@...r.kernel.org
Subject: Re: 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/