linux-kernel - 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>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Jul 2007 05:38:13 +0200
From:	Zeus Gómez Marmolejo <zeus@...zina.org>
To:	linux-kernel@...r.kernel.org
Subject: New LSM security operation

Hi people,

I've looked around on how to hide inodes in a Linux filesystem but 
surprisingly the kernel lacks this functionality. It would be desirable 
for me to add an ACL to a file in order not to be seen in the directory 
contents but only for some users.

Some Selinux experts point out that the correct way to do this is via 
poly-instantiated directories such as /tmp or /var/tmp, so each user 
"view" his own version of this directory. But that's not what I want, 
for example in /etc, I would want to hide some directories or files for 
some users. I don't want a whole /etc instantiation for each user logged in.

Also, there is a patch called LIDS that does the thing, but patching the 
whole kernel and adding much extra functionality such as intrussion 
detection system as it is. Some rootkits -like adore- also can hide 
inodes, but changing the owner to an uid that the kernel module hides 
from the system call. I don't thing this is a good approach...

For me, the correct way to achieve this is to add an extra op in the 
"security_operations" struct, as an inode operation. With this, a 
Mandatory Access Control system that uses LSM such as SELinux can add 
some policies on the "list" file access vector.

So, I'd call this hook in the vfs_readdir() syscall just after the "file 
<http://lxr.linux.no/ident?i=file>->f_op->readdir()" -the particular 
filesystem readdir()- and walk through the list to ask for each inode if 
it has permission to be "listed" in that directory. Then, the MAC system 
can handle the grant or deny permission per inode, and then return the 
"modified" list to userspace.

I'm not sure if this is the correct way, or maybe it adds to much 
overhead to the "ls" command, but I'd like to hear some opinions, I can 
try to code it and summit a patch...

Thanks for your answer,

Zeus Gómez.
PS. Please, include me in the CC if you reply this message.
-
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/