Re: [PATCH][RFC] Simple tamper-proof device filesystem.
On Sun, Jan 06, 2008 at 04:36:06PM +0900, Tetsuo Handa wrote: > 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 feature depends > > on TMPFS too. > > > > Judging from the following comment : > > * Original tmpfs doesn't set ramfs_dir_inode_operations.setattr field. > > > > I suspect that you confuse both filesystems. > > - ramfs is in fs/ramfs and is always compiled in, you cannot disable it > > - tmpfs is in mm/shmem.c and is optional. It also supports options that > > ramfs does not (eg: size) and data may be swapped. > > > > Please understand that I'm not discussing the usefulness of your patch, > > I'm just trying to avoid a huge confusion. > > Oh, I thought the filesystem mounted by "mount -t tmpfs none /tmp" is "tmpfs" Yes, that is a tmpfs. > and the source code of "tmpfs" is located in fs/ramfs directory. No, ramfs is what you get by "mount -t ramfs none /tmp" :-) You will notice that "df" will not report your ramfs by default because it reports zero blocks. But "mount" or "df /tmp" will report it. > So, I should write the description as "an extension to ramfs" rather than > "an extension to tmpfs". and please also the comments, macros and variable names in the code, as they are what confused me first. > I'll fix it in next posting. Thanks, Willy - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] Simple tamper-proof device filesystem.
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 feature depends > on TMPFS too. > > Judging from the following comment : > * Original tmpfs doesn't set ramfs_dir_inode_operations.setattr field. > > I suspect that you confuse both filesystems. > - ramfs is in fs/ramfs and is always compiled in, you cannot disable it > - tmpfs is in mm/shmem.c and is optional. It also supports options that > ramfs does not (eg: size) and data may be swapped. > > Please understand that I'm not discussing the usefulness of your patch, > I'm just trying to avoid a huge confusion. Oh, I thought the filesystem mounted by "mount -t tmpfs none /tmp" is "tmpfs" and the source code of "tmpfs" is located in fs/ramfs directory. So, I should write the description as "an extension to ramfs" rather than "an extension to tmpfs". I'll fix it in next posting. Thank you. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] Simple tamper-proof device filesystem.
Hello, On Sun, Jan 06, 2008 at 03:20:00PM +0900, Tetsuo Handa wrote: > Hello. > > Changes from previous posting: > > (1) Added kernel config so that users can choose > whether to compile this filesystem or not. > > I didn't receive any ACK/NACK regarding whether I'm permitted to > implement this filesystem as an extension to tmpfs or not. > So, I continued implementing this filesystem as an extension to tmpfs. > > (2) Removed indirect grabbing of blkdev_open() and chrdev_open(). > > The previous posting was using indirect approach to call > blkdev_open() and chrdev_open() so that users can compile > this filesystem as a module without exporting blkdev_open() > from fs/block_dev.c and chrdev_open() from fs/char_dev.c . > But since tmpfs cannot be compiled as a module, > I changed it to direct accessing. > > (3) Splitted single file into three files. > > syaoran_init.c: initialization part > syaoran_main.c: access control part > syaoran_debug.c: taking snapshot part > > This patch is for 2.6.24-rc6-mm1. > > Regards. > -- > Subject: Simple tamper-proof device filesystem. > > The goal of this filesystem is to guarantee that > "applications using well-known device locations under /dev > get the device they want" (e.g. an application that accesses /dev/null can > always get a character special device with major=1 and minor=3). > > This idea sounds silly? Indeed, if you think the root can do whatever > he/she wants do do. But this filesystem makes sense when used with > access control mechanisms like MAC (mandatory access control). > 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. > > Why not use FUSE? > > Because /dev has to be available through the lifetime of the kernel. > It is not acceptable if /dev stops working due to SIGKILL or OOM-killer. > > Why not use SELinux? > > Because SELinux doesn't guarantee filename and its attribute. > As far as I know, no MAC implementation can handle filename and its > attribute. > I guess this is because > > Filename and its attributes pairs are conventionally considered as > constant and reliable. > > It makes the MAC's policy syntax complicated to describe this attribute > enforcement information in MAC's policy. > > I want to add functionality that the MACs are missing. > Instead of adding this functionality per MAC, > I propose to add it as ground work, to be combined with any MAC. > > Why not drop CAP_MKNOD? > > Dropping CAP_MKNOD is not enough for emulating this filesystem because > a process can still rename()/unlink() to break filename and its attributes > handling (e.g. mv /dev/sda1 /dev/sda1.tmp; mv /dev/sda2 /dev/sda1; > mv /dev/sda1.tmp /dev/sda2 or unlink /dev/null; 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/inode.c | 177 ++ > fs/ramfs/syaoran.h | 75 ++ > fs/ramfs/syaoran_debug.c | 183 +++ > fs/ramfs/syaoran_init.c | 568 > +++ > fs/ramfs/syaoran_main.c | 207 + > 6 files changed, 1222 insertions(+), 6 deletions(-) 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 feature depends on TMPFS too. Judging from the following comment : * Original tmpfs doesn't set ramfs_dir_inode_operations.setattr field. I suspect that you confuse both filesystems. - ramfs is in fs/ramfs and is always compiled in, you cannot disable it - tmpfs is in mm/shmem.c and is optional. It also supports options that ramfs does not (eg: size) and data may be swapped. Please understand that I'm not discussing the usefulness of your patch, I'm just trying to avoid a huge confusion. Regards, Willy > --- linux-2.6-mm.orig/fs/ramfs/inode.c > +++ linux-2.6-mm/fs/ramfs/inode.c > @@ -36,6 +36,20 @@ > #include > #include "internal.h" > > +static struct inode *__ramfs_get_inode(struct super_block *sb, int mode, > +dev_t dev, bool tmpfs_with_mac); > + > +#define TMPFS_WITH_MAC1 > +#define TMPFS_WITHOUT_MAC 0 > +#include > + > +#ifdef CONFIG_SYAORAN > +#include "syaoran.h" > +#include "syaoran_init.c" > +#include "syaoran_main.c" > +#include "syaoran_debug.c" > +#endif > + > /* some random number */ > #define RAMFS_MAGIC 0x858458f6 > > @@ -51,6 +65,12 @@ static struct backing_dev_info ramfs_bac > >
[PATCH][RFC] Simple tamper-proof device filesystem.
Hello.
Changes from previous posting:
(1) Added kernel config so that users can choose
whether to compile this filesystem or not.
I didn't receive any ACK/NACK regarding whether I'm permitted to
implement this filesystem as an extension to tmpfs or not.
So, I continued implementing this filesystem as an extension to tmpfs.
(2) Removed indirect grabbing of blkdev_open() and chrdev_open().
The previous posting was using indirect approach to call
blkdev_open() and chrdev_open() so that users can compile
this filesystem as a module without exporting blkdev_open()
from fs/block_dev.c and chrdev_open() from fs/char_dev.c .
But since tmpfs cannot be compiled as a module,
I changed it to direct accessing.
(3) Splitted single file into three files.
syaoran_init.c: initialization part
syaoran_main.c: access control part
syaoran_debug.c: taking snapshot part
This patch is for 2.6.24-rc6-mm1.
Regards.
--
Subject: Simple tamper-proof device filesystem.
The goal of this filesystem is to guarantee that
"applications using well-known device locations under /dev
get the device they want" (e.g. an application that accesses /dev/null can
always get a character special device with major=1 and minor=3).
This idea sounds silly? Indeed, if you think the root can do whatever
he/she wants do do. But this filesystem makes sense when used with
access control mechanisms like MAC (mandatory access control).
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.
Why not use FUSE?
Because /dev has to be available through the lifetime of the kernel.
It is not acceptable if /dev stops working due to SIGKILL or OOM-killer.
Why not use SELinux?
Because SELinux doesn't guarantee filename and its attribute.
As far as I know, no MAC implementation can handle filename and its attribute.
I guess this is because
Filename and its attributes pairs are conventionally considered as
constant and reliable.
It makes the MAC's policy syntax complicated to describe this attribute
enforcement information in MAC's policy.
I want to add functionality that the MACs are missing.
Instead of adding this functionality per MAC,
I propose to add it as ground work, to be combined with any MAC.
Why not drop CAP_MKNOD?
Dropping CAP_MKNOD is not enough for emulating this filesystem because
a process can still rename()/unlink() to break filename and its attributes
handling (e.g. mv /dev/sda1 /dev/sda1.tmp; mv /dev/sda2 /dev/sda1;
mv /dev/sda1.tmp /dev/sda2 or unlink /dev/null; 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/inode.c | 177 ++
fs/ramfs/syaoran.h | 75 ++
fs/ramfs/syaoran_debug.c | 183 +++
fs/ramfs/syaoran_init.c | 568 +++
fs/ramfs/syaoran_main.c | 207 +
6 files changed, 1222 insertions(+), 6 deletions(-)
--- linux-2.6-mm.orig/fs/ramfs/inode.c
+++ linux-2.6-mm/fs/ramfs/inode.c
@@ -36,6 +36,20 @@
#include
#include "internal.h"
+static struct inode *__ramfs_get_inode(struct super_block *sb, int mode,
+ dev_t dev, bool tmpfs_with_mac);
+
+#define TMPFS_WITH_MAC1
+#define TMPFS_WITHOUT_MAC 0
+#include
+
+#ifdef CONFIG_SYAORAN
+#include "syaoran.h"
+#include "syaoran_init.c"
+#include "syaoran_main.c"
+#include "syaoran_debug.c"
+#endif
+
/* some random number */
#define RAMFS_MAGIC0x858458f6
@@ -51,6 +65,12 @@ static struct backing_dev_info ramfs_bac
struct inode *ramfs_get_inode(struct super_block *sb, int mode, dev_t dev)
{
+ return __ramfs_get_inode(sb, mode, dev, TMPFS_WITHOUT_MAC);
+}
+
+static struct inode *__ramfs_get_inode(struct super_block *sb, int mode,
+ dev_t dev, const bool tmpfs_with_mac)
+{
struct inode * inode = new_inode(sb);
if (inode) {
@@ -65,10 +85,18 @@ struct inode *ramfs_get_inode(struct sup
switch (mode & S_IFMT) {
default:
init_special_inode(inode, mode, dev);
+#ifdef CONFIG_SYAORAN
+ if (tmpfs_with_mac)
+ init_syaoran_inode(inode, mode);
+#endif
break;
case S_IFREG:
inode->i_op = &ramfs_file_inode_operations;
inode->i_fop = &ramfs_file_operations;
+#ifdef CONFIG_SYAORAN
+ if (tmpfs_with_mac)
+ init_syaoran_inode(inode, mode);
+#endif
break;
Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2
Hello, On Jan 5, 2008 10:31 AM, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak <[EMAIL PROTECTED]> wrote: > > The second util-linux-ng 2.13.1 release candidate is available at > > > > ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/ > > > > Interesting. Thanks. Which distros are using this, or plan to do so? > I have added util-linux-ng to the OpenEmbedded project a few days ago, so any distro in there can switch over. Regards, -- Leon - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2
On Sat, 5 Jan 2008 01:31:21 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak <[EMAIL PROTECTED]> wrote: > > > > > > > The second util-linux-ng 2.13.1 release candidate is available at > > > > ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/ > > > > Interesting. Thanks. Which distros are using this, or plan to do so? Fedora switched quite a bit ago. That shouldn't be a surprise given the maintainer's affiliation :) josh - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2
Saturday 05 January 2008 11:31:21 tarihinde şunları yazmıştınız: > On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak <[EMAIL PROTECTED]> wrote: > > The second util-linux-ng 2.13.1 release candidate is available at > > > > ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/ > > Interesting. Thanks. Which distros are using this, or plan to do so? Pardus Linux switched to -ng for upcoming 2008 release. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2
On Jan 5 2008 01:31, Andrew Morton wrote: >> The second util-linux-ng 2.13.1 release candidate is available at >> >> ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/ >> > >Interesting. Thanks. Which distros are using this, or plan to do so? SUSE does. Practically, the first util-linux-ng already replaced util-linux. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: On setting a lease across a cluster
> > actually doing most of what you've just suggested here, which i take to be > > a good sign. > > As long as it's great minds thinking alike and not fools seldom > differing ;-) ooh, good phrase, one with which i wasn't familiar :) > > most of my refactoring came out of trying to simplify locking and > > avoid holding locks too long (rather than specifically focusing on > > cluster-oriented stuff, but the goals dovetail) and your work on getting > > the BKL out of locks.c entirely is something i really like and look > > forward to. > > Excellent. Shall I make the patch myself, or did you want to post a > patch based on working code? ;-) please, by all means, keep going -- i want your code! :) my wording was poor and may've sounded like this was already a fait accompli, when basically what i was trying to say was that the locking ended up being a hassle and your approach would also help solve that, in addition to your extra cluster-related needs/goals. thanks, d . - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2
Andrew Morton wrote: > On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak <[EMAIL PROTECTED]> wrote: > >> >> The second util-linux-ng 2.13.1 release candidate is available at >> >> ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/ >> > > Interesting. Thanks. Which distros are using this, or plan to do so? We use util-linux-ng in Frugalware Linux for quite some time now. Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2
On Saturday 05 January 2008, Samuel Thibault wrote: > Clemens Koller, le Sat 05 Jan 2008 15:51:57 +0100, a écrit : > > Andrew Morton schrieb: > > >On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak <[EMAIL PROTECTED]> wrote: > > >> The second util-linux-ng 2.13.1 release candidate is available at > > >> > > >>ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/ > > > > > >Interesting. Thanks. Which distros are using this, or plan to do so? > > > > We (CRUX community, http://crux.nu ) just switched to the -ng. > > debian has switched since July 2007 at least. Gentoo is in about the same time frame ... we moved it to stable in ~October -mike signature.asc Description: This is a digitally signed message part.
Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2
Clemens Koller, le Sat 05 Jan 2008 15:51:57 +0100, a écrit : > Andrew Morton schrieb: > >On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak <[EMAIL PROTECTED]> wrote: > > > >> > >> The second util-linux-ng 2.13.1 release candidate is available at > >> > >>ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/ > >> > > > >Interesting. Thanks. Which distros are using this, or plan to do so? > > We (CRUX community, http://crux.nu ) just switched to the -ng. debian has switched since July 2007 at least. Samuel - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2
Andrew Morton schrieb: On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak <[EMAIL PROTECTED]> wrote: The second util-linux-ng 2.13.1 release candidate is available at ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/ Interesting. Thanks. Which distros are using this, or plan to do so? We (CRUX community, http://crux.nu ) just switched to the -ng. The old non -ng version doesn't seem to be maintained well. Regards, -- Clemens Koller ___ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2
On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak <[EMAIL PROTECTED]> wrote: > > > The second util-linux-ng 2.13.1 release candidate is available at > > ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/ > Interesting. Thanks. Which distros are using this, or plan to do so? - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
