Hello.
No printable comments, except for that:
(e) why don't you guys move the Linus' Serious Mistake to _callers_ of
vfs_mknod() and its ilk?
Which obviously solves all problems with having vfsmount.
Excuse me. I didn't understand what the Linus' Serious Mistake to
_callers_ of
Hello.
Indan Zupancic wrote:
It seems to me that the alternatives you are proposing include
modification of userland applications. But my assumption is
that Don't require modification of userland applications.
If you want a secure system it isn't that unreasonable to expect
Hello.
Indan Zupancic wrote:
That only the tiny daemon can modify /dev/ is done with MAC rules,
the ones that should be the default for all applications except udev by
default already. For teh kernel nothing changes.
OK. You assume use of MAC with enough fine grained access control.
Hello.
Indan Zupancic wrote:
Good point, but I assume they all have at least a directory granularity, and
then
/dev/ can be static and udev and other can have free reign in e.g.
/dev/dynamic/.
Just use subdirs for the dynamic stuff and this granularity problem is, with
slight
Hello.
Indan Zupancic wrote:
I want to use this filesystem in case where a process with root privilege
was
hijacked but the behavior of the hijacked process is still restricted by
MAC.
1) If the behaviour can be controlled, why can't the process be
disallowed to change anything
Hello.
[EMAIL PROTECTED] wrote:
Ouch. The .c files should generally be built into their own .o files and
then the Makefile should do something like
obj-$(CONFIG_SYAORAN) += syaoran.o
unless there's *really* good reasons for including .c files (such as an
otherwise-messy
Hello.
Indan Zupancic wrote:
I think you focus too much on your way of enforcing filename/attributes
pairs.
So?
The same can be achieved by creating the device nodes with
expected attributes, and preventing processes from changing those files.
The device nodes have to be deletable if some
Hello.
[EMAIL PROTECTED] wrote:
Good summary - probably should add that to the patch, drop it into
Documentation/syaoran-config.txt or similar...
I see.
Modification while reading *is* an issue, but can probably be worked around
with some clever locking. The race condition I was thinking of
.
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
fs/Kconfig | 18 +
include/linux/shmem_fs.h |5
mm/shmem.c | 124 +++
mm/shmem_mac.h | 57 +
mm/shmem_mac_debug.c | 183 +
mm/shmem_mac_init.c | 486
; touch /dev/null ).
This time, I'm implementing this filesystem as an extension to tmpfs
because what this filesystem does are nothing but check filename and
its attributes in addition to what tmpfs does.
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
fs/Kconfig | 18 +
fs/ramfs
Hello.
Willy Tarreau wrote:
Your patch is very confusing. In your description, as well as in the
comments you talk about tmpfs, but your patch does not touch even one
line of tmpfs and only changes ramfs. Even your variables and arguments
refer to tmpfs. The Kconfig entry indicates that the
Hello.
Serge E. Hallyn wrote:
I apologize if I'm commiting a faux pas by asking this, but any chance
of renaming this to something like strictdev or sdev, or at least with
'dev' in it somewhere?
You are not commiting a faux pas. But, this naming is my personal feeling. ;-)
You can see the
).
This time, I'm implementing this filesystem as an extension to tmpfs
because what this filesystem does are nothing but check filename and
its attributes in addition to what tmpfs does.
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
fs/ramfs/inode.c | 101 -
fs/ramfs/syaoran.h | 1066
Hello.
Radoslaw Szkodzinski (AstralStorm) wrote:
Actually, who needs to create device nodes? Just prohibit everyone from
creating them, except installer and udev personality.
This means removing CAP_MKNOD on a global scale.
What happens if the root tampers udev's configuration file?
The udev
Hello.
Indan Zupancic wrote:
If MAC can avoid all that, then why can't it also avoid tampering with /dev?
If MAC implementation handles filename and its attributes pair, this filesystem
is not needed.
But I don't know MAC implementations that handle this pair.
SELinux's granularity is allow
Hello.
Al Boldi wrote:
I think the answer is obvious: Tetsuo wants to add functionality that the
MACs are missing. So, instead of adding this functionality per MAC, he
proposes to add it as ground work, to be combined with any MAC.
Yes, that's right.
This filesystem is designed to be used
( This is a reply to http://lkml.org/lkml/2007/12/17/27 .)
Hello.
David Wagner wrote:
But the point is that it's not enough just to prevent attackers
from mounting other filesystems over this filesystem. I can think
of all sorts of ways that an admin-level attacker might be able to
prevent
Hello.
Serge E. Hallyn wrote:
CAP_MKNOD will be removed from its capability
I think it is not enough because the root can rename/unlink device files
(mv /dev/sda1 /dev/tmp; mv /dev/sda2 /dev/sda1; mv /dev/tmp /dev/sda2).
To use your approach, i guess we would have to use selinux (or tomoyo)
Hello.
Serge E. Hallyn wrote:
But your requirements are to ensure that an application accessing a
device at a well-known location get what it expect.
Yes. That's the purpose of this filesystem.
So then the main quesiton is still the one I think Al had asked - what
keeps a rogue
Hello.
Serge E. Hallyn wrote:
Nope, try
touch /root/hda1
ls -l /root/hda1
mount --bind /dev/hda1 /root/hda1
ls -l /root/hda1
[EMAIL PROTECTED] ~]# touch /root/hda1
[EMAIL PROTECTED] ~]# ls -l /root/hda1
-rw-r--r-- 1 root root 0 Dec 18 12:04 /root/hda1
[EMAIL PROTECTED] ~]# mount
Hello.
I have proposed this filesystem a few years ago.
Once again, I'm proposing this filesystem toward inclusion into mainline.
I'll update for -mm tree if this filesystem is likely acceptable.
Regards.
(This is a resent message of [00/02] since it seems to be dropped.)
-
To unsubscribe from
SELinux doesn't guarantee filename and its attribute.
The purpose of this filesystem is to ensure filename and its attribute
(e.g. /dev/null is guaranteed to be a character device file
with major=1 and minor=3).
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
fs/syaoran/syaoran.c | 338
Signed-off-by: Tetsuo Handa [EMAIL PROTECTED]
---
fs/Kconfig | 21 +
fs/Makefile |1 +
2 files changed, 22 insertions(+)
--- linux-2.6.24-rc5.orig/fs/Kconfig
+++ linux-2.6.24-rc5/fs/Kconfig
@@ -1555,6 +1555,27 @@ config UFS_DEBUG
Y here. This will result
Hello.
David Newall wrote:
Tetsuo Handa wrote:
/dev needs to be writable, but this means that files on /dev might be
tampered with.
I infer that you mean /dev needs to be writable by anyone, not by just
its owner or owner and group (conventionally root/root.) This goes
against
Hello.
I meant that /dev must be mounted for read-write mode
Again, why?
You can mount / partition for read-only mode if you wish to do so.
But you cannot make /dev directory for read-only.
You won't be able to login to the system because /sbin/mingetty
fails to chown/chmod /dev/tty* if
But use of this filesystem is still valid when this filesystem is used with
policy based mandatory access control (such as SELinux, TOMOYO Linux)
because this filesystem guarantees where policy based mandatory access control
can't guarantee (i.e. filename and its attribute).
Policy based
Hello.
Indan Zupancic wrote:
What prevents them from mounting tmpfs on top of /dev, bypassing your fs?
Mandatory access control (MAC) prevents them from mounting tmpfs on top of /dev
.
MAC mediates namespace manipulation requests such as mount()/umount().
Also, if they have root there are
Hello.
Christoph Hellwig wrote:
Isn't security_inode_create() a part of VFS internals?
It's not. security_inode_create is part of the LSM infrastructure, and
the actual methods are part of security modules and definitively not
VFS internals.
The reason why I want to access namespace_sem
Hello.
Christoph Hellwig wrote:
Same argument as with the AA folks: it does not have any business looking
at the vfsmount. If you create a file it can and in many setups will
show up in multiple vfsmounts, so making decisions based on the particular
one this creat happens through is wrong
Hello.
Christoph Hellwig wrote:
Any code except VFS internals has no business using it at all and doesn't
do that in mainline either. I'd start looking for design bugs in whatever
code you have using it first.
Isn't security_inode_create() a part of VFS internals?
I think
Hello.
I'm running my LSM module on kernel 2.6.23 / Debian Sarge.
I encountered the following warning message.
It seems that calling down_read(namespace_sem) is not permitted
inside mutex_lock(inode-i_mutex) , but I'm not sure.
Is it illegal to refer namespace_sem while inode's mutex held?
Hello.
I found that accessing namespace_sem from security_inode_create()
causes lockdep warning when compiled with CONFIG_PROVE_LOCKING=y .
===
[ INFO: possible circular locking dependency detected ]
Hello.
Arjan van de Ven wrote:
when will you post this filesystem for inclusion into kernel.org kernel?
(and please really consider posting the patch together with that patch)
(also, if you can give a pointer to the source code of this filesystem
you might even get early code review)
I have
Hello.
What filesystem are you using? ext3? ext4? xfs? And are you using
any non-standard patches, such as some of the delayed allocation
patches that have been floating around? If you're using ext3, that
shouldn't be happening.
I'm using ext3.
I'm running it on kernel
Hello.
Theodore Tso wrote:
Secondly, what results do you get when you run the command hdparm -tT
/dev/sda (or /dev/hda if you are using an IDE disk)?
[EMAIL PROTECTED] Ubuntu7.10]# hdparm -tT /dev/hda1
/dev/hda1:
Timing cached reads: 10384 MB in 2.00 seconds = 5196.44 MB/sec
Timing
Hello.
Theodore Tso wrote:
beginning of every single block group. You have a small number of
files on your system (349) occupying an average of 348 megabytes. So
it's not at all surprising that the contiguous percentage is 32%.
I see, thank you. Yes, there are many files splitted in 2GB
Hello.
I ran e2fsck and it reported as follows.
[EMAIL PROTECTED] ~]# e2fsck -f /dev/hda1
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group
Hello.
Andreas Gruenbacher wrote:
exec { /usr/bin/gunzip } gzip, -9, some/file/to.gz;
The above Perl code executes /usr/bin/gunzip and sets argv[0] to gzip, so
this confirms that the value of argv[0] is arbitrary. Well great, we already
knew.
AppArmor does not look at argv[0] for
Hello.
Andreas Gruenbacher wrote:
Therefore, TOMOYO Linux checks the combination of filename and argv[0]
passed to execve().
So you are indeed trying to control the value of argv[0]? Well, good luck
with
that, but it's totally insane. You are guaranteed to break some applications.
TOMOYO
Hello.
Casey Schaufler wrote:
Sorry, but I don't understand your objection. If AppArmor is configured
to allow everyone access to /bin/gzip but only some people access to
/bin/gunzip and (important detail) the single binary uses argv[0]
as documented and (another important detail) there
Hello.
I think bind mounts were discussed when shared subtree
( http://lwn.net/Articles/159092/ ) was introduced.
For systems that allow users mount their CD/DVDs freely,
bind mounts are used and labeling files is a convenient way
to deny accessing somebody else's files.
But systems that don't
Hello.
I've just returned from ELC2007 and
I haven't read all posts in this thread yet,
but I want to comment to this function.
In AppArmor, we are interested in pathnames relative to the namespace root.
This is the same as d_path() except for the root where the search ends. Add
a function
Tony Jones wrote:
The following are a set of patches the goal of which is to pass vfsmounts
through select portions of the VFS layer sufficient to be visible to the LSM
inode operation hooks.
I was looking forward to these patches for so long.
Chris Wright wrote:
This kind of change (or
43 matches
Mail list logo
