From: "Serge E. Hallyn" <serge@hallyn.com>
To: "Zeus Gómez Marmolejo" <zeus@aluzina.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: New LSM security operation
Date: Thu, 12 Jul 2007 13:17:08 -0500 [thread overview]
Message-ID: <20070712181708.GA28760@vino.hallyn.com> (raw)
In-Reply-To: <4695A225.6050807@aluzina.org>
Quoting Zeus Gómez Marmolejo (zeus@aluzina.org):
> 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.
That's how it is often done elsewhere, but (at least until now) the
correct way to achieve this in Linux is to make use of either
per-process namespaces or chroots. For example, either create custom fs
trees for each user under /share/ and chroot user hallyn under /share/hallyn
upon login, or, upon login, create a new mounts namespace and massage
the fs tree there.
For persistant filesystems, you can of course keep custom versions of
the filesystems in hidden directories. I.e. under /tmp/ you could
keep /tmp/.priv/hallyn, and, when hallyn logs in, do
mount --bind /tmp/.priv/hallyn /tmp
or if you're going the /share route, just do
mount --bind /share/hallyn/tmp/.priv/hallyn /share/hallyn/tmp
while setting up your trees after boot.
For procfs and sysfs, the containers (specifically process id namespaces
and network namespaces) are starting some of the work to support
showing only authorized data to containers.
-serge
> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2007-07-12 18:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-12 3:38 Zeus Gómez Marmolejo
2007-07-12 18:17 ` Serge E. Hallyn [this message]
[not found] <986851.77016.qm@web36607.mail.mud.yahoo.com>
2007-07-12 5:21 ` Zeus Gómez Marmolejo
[not found] <883505.60477.qm@web36609.mail.mud.yahoo.com>
2007-07-13 2:42 ` Zeus Gómez Marmolejo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070712181708.GA28760@vino.hallyn.com \
--to=serge@hallyn.com \
--cc=linux-kernel@vger.kernel.org \
--cc=zeus@aluzina.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®