Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 origin at http://I-love.SAKURA.ne.jp/tomoyo/index-en.html . Happy Holidays! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 origin at http://I-love.SAKURA.ne.jp/tomoyo/index-en.html . Happy Holidays! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Pavel Emelyanov wrote: > Oren Laadan wrote: >> Serge E. Hallyn wrote: >>> Quoting Pavel Emelyanov ([EMAIL PROTECTED]): Oren Laadan wrote: > Serge E. Hallyn wrote: >> Quoting Oren Laadan ([EMAIL PROTECTED]): >>> I hate to bring this again, but what if the admin in the container >>> mounts an external file system (eg. nfs, usb, loop mount from a file, >>> or via fuse), and that file system already has a device that we would >>> like to ban inside that container ? >> Miklos' user mount patches enforced that if !capable(CAP_MKNOD), >> then mnt->mnt_flags |= MNT_NODEV. So that's no problem. > Yes, that works to disallow all device files from a mounted file system. > > But it's a black and white thing: either they are all banned or allowed; > you can't have some devices allowed and others not, depending on type > A scenario where this may be useful is, for instance, if we some apps in > the container to execute withing a pre-made chroot (sub)tree within that > container. > >> But that's been pulled out of -mm! ? Crap. >> >>> Since anyway we will have to keep a white- (or black-) list of devices >>> that are permitted in a container, and that list may change even change >>> per container -- why not enforce the access control at the VFS layer ? >>> It's safer in the long run. >> By that you mean more along the lines of Pavel's patch than my whitelist >> LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean >> that >> by 'vfs layer' :), or something different entirely? > :) > > By 'vfs' I mean at open() time, and not at mount(), or mknod() time. > Either yours or Pavel's; I tend to prefer not to use LSM as it may > collide with future security modules. Oren, AFAIS you've seen my patches for device access controller, right? >> If you mean this one: >> http://openvz.org/pipermail/devel/2007-September/007647.html >> then ack :) > > Great! Thanks. > Maybe we can revisit the issue then and try to come to agreement on what kind of model and implementation we all want? >>> That would be great, Pavel. I do prefer your solution over my LSM, so >>> if we can get an elegant block device control right in the vfs code that >>> would be my preference. >> I concur. >> >> So it seems to me that we are all in favor of the model where open() >> of a device will consult a black/white-list. Also, we are all in favor >> of a non-LSM implementation, Pavel's code being a good example. > > Thank you, Oren and Serge! I will revisit this issue then, but > I have a vacation the next week and, after this, we have a New > Year and Christmas holidays in Russia. So I will be able to go > on with it only after the 7th January :( Hope this is OK for you. > > Besides, Andrew told that he would pay little attention to new > features till the 2.6.24 release, so I'm afraid we won't have this > even in -mm in the nearest months :( Sounds great ! (as for the delay, it wasn't the highest priority issue to begin with, so no worries). Ah.. coincidentally they are celebrated here, too, on the same time :D Merry Christmas and Happy New Year ! Oren. > > Thanks, > Pavel > >> Oren. >> >>> The only thing that makes me keep wanting to go back to an LSM is the >>> fact that the code defining the whitelist seems out of place in the vfs. >>> But I guess that's actually separated into a modular cgroup, with the >>> actual enforcement built in at the vfs. So that's really the best >>> solution. >>> >>> -serge > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Pavel Emelyanov ([EMAIL PROTECTED]): > Oren Laadan wrote: > > > > Serge E. Hallyn wrote: > >> Quoting Pavel Emelyanov ([EMAIL PROTECTED]): > >>> Oren Laadan wrote: > Serge E. Hallyn wrote: > > Quoting Oren Laadan ([EMAIL PROTECTED]): > >> I hate to bring this again, but what if the admin in the container > >> mounts an external file system (eg. nfs, usb, loop mount from a file, > >> or via fuse), and that file system already has a device that we would > >> like to ban inside that container ? > > Miklos' user mount patches enforced that if !capable(CAP_MKNOD), > > then mnt->mnt_flags |= MNT_NODEV. So that's no problem. > Yes, that works to disallow all device files from a mounted file system. > > But it's a black and white thing: either they are all banned or allowed; > you can't have some devices allowed and others not, depending on type > A scenario where this may be useful is, for instance, if we some apps in > the container to execute withing a pre-made chroot (sub)tree within that > container. > > > But that's been pulled out of -mm! ? Crap. > > > >> Since anyway we will have to keep a white- (or black-) list of devices > >> that are permitted in a container, and that list may change even change > >> per container -- why not enforce the access control at the VFS layer ? > >> It's safer in the long run. > > By that you mean more along the lines of Pavel's patch than my whitelist > > LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean > > that > > by 'vfs layer' :), or something different entirely? > :) > > By 'vfs' I mean at open() time, and not at mount(), or mknod() time. > Either yours or Pavel's; I tend to prefer not to use LSM as it may > collide with future security modules. > >>> Oren, AFAIS you've seen my patches for device access controller, right? > > > > If you mean this one: > > http://openvz.org/pipermail/devel/2007-September/007647.html > > then ack :) > > Great! Thanks. > > >>> Maybe we can revisit the issue then and try to come to agreement on what > >>> kind of model and implementation we all want? > >> That would be great, Pavel. I do prefer your solution over my LSM, so > >> if we can get an elegant block device control right in the vfs code that > >> would be my preference. > > > > I concur. > > > > So it seems to me that we are all in favor of the model where open() > > of a device will consult a black/white-list. Also, we are all in favor > > of a non-LSM implementation, Pavel's code being a good example. > > Thank you, Oren and Serge! I will revisit this issue then, but > I have a vacation the next week and, after this, we have a New > Year and Christmas holidays in Russia. So I will be able to go > on with it only after the 7th January :( Hope this is OK for you. > > Besides, Andrew told that he would pay little attention to new > features till the 2.6.24 release, so I'm afraid we won't have this > even in -mm in the nearest months :( > > Thanks, > Pavel Cool, let me know any way I can help when you get started. thanks, -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Pavel Emelyanov ([EMAIL PROTECTED]): Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Pavel Emelyanov ([EMAIL PROTECTED]): Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): I hate to bring this again, but what if the admin in the container mounts an external file system (eg. nfs, usb, loop mount from a file, or via fuse), and that file system already has a device that we would like to ban inside that container ? Miklos' user mount patches enforced that if !capable(CAP_MKNOD), then mnt-mnt_flags |= MNT_NODEV. So that's no problem. Yes, that works to disallow all device files from a mounted file system. But it's a black and white thing: either they are all banned or allowed; you can't have some devices allowed and others not, depending on type A scenario where this may be useful is, for instance, if we some apps in the container to execute withing a pre-made chroot (sub)tree within that container. But that's been pulled out of -mm! ? Crap. Since anyway we will have to keep a white- (or black-) list of devices that are permitted in a container, and that list may change even change per container -- why not enforce the access control at the VFS layer ? It's safer in the long run. By that you mean more along the lines of Pavel's patch than my whitelist LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that by 'vfs layer' :), or something different entirely? :) By 'vfs' I mean at open() time, and not at mount(), or mknod() time. Either yours or Pavel's; I tend to prefer not to use LSM as it may collide with future security modules. Oren, AFAIS you've seen my patches for device access controller, right? If you mean this one: http://openvz.org/pipermail/devel/2007-September/007647.html then ack :) Great! Thanks. Maybe we can revisit the issue then and try to come to agreement on what kind of model and implementation we all want? That would be great, Pavel. I do prefer your solution over my LSM, so if we can get an elegant block device control right in the vfs code that would be my preference. I concur. So it seems to me that we are all in favor of the model where open() of a device will consult a black/white-list. Also, we are all in favor of a non-LSM implementation, Pavel's code being a good example. Thank you, Oren and Serge! I will revisit this issue then, but I have a vacation the next week and, after this, we have a New Year and Christmas holidays in Russia. So I will be able to go on with it only after the 7th January :( Hope this is OK for you. Besides, Andrew told that he would pay little attention to new features till the 2.6.24 release, so I'm afraid we won't have this even in -mm in the nearest months :( Thanks, Pavel Cool, let me know any way I can help when you get started. thanks, -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Pavel Emelyanov wrote: Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Pavel Emelyanov ([EMAIL PROTECTED]): Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): I hate to bring this again, but what if the admin in the container mounts an external file system (eg. nfs, usb, loop mount from a file, or via fuse), and that file system already has a device that we would like to ban inside that container ? Miklos' user mount patches enforced that if !capable(CAP_MKNOD), then mnt-mnt_flags |= MNT_NODEV. So that's no problem. Yes, that works to disallow all device files from a mounted file system. But it's a black and white thing: either they are all banned or allowed; you can't have some devices allowed and others not, depending on type A scenario where this may be useful is, for instance, if we some apps in the container to execute withing a pre-made chroot (sub)tree within that container. But that's been pulled out of -mm! ? Crap. Since anyway we will have to keep a white- (or black-) list of devices that are permitted in a container, and that list may change even change per container -- why not enforce the access control at the VFS layer ? It's safer in the long run. By that you mean more along the lines of Pavel's patch than my whitelist LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that by 'vfs layer' :), or something different entirely? :) By 'vfs' I mean at open() time, and not at mount(), or mknod() time. Either yours or Pavel's; I tend to prefer not to use LSM as it may collide with future security modules. Oren, AFAIS you've seen my patches for device access controller, right? If you mean this one: http://openvz.org/pipermail/devel/2007-September/007647.html then ack :) Great! Thanks. Maybe we can revisit the issue then and try to come to agreement on what kind of model and implementation we all want? That would be great, Pavel. I do prefer your solution over my LSM, so if we can get an elegant block device control right in the vfs code that would be my preference. I concur. So it seems to me that we are all in favor of the model where open() of a device will consult a black/white-list. Also, we are all in favor of a non-LSM implementation, Pavel's code being a good example. Thank you, Oren and Serge! I will revisit this issue then, but I have a vacation the next week and, after this, we have a New Year and Christmas holidays in Russia. So I will be able to go on with it only after the 7th January :( Hope this is OK for you. Besides, Andrew told that he would pay little attention to new features till the 2.6.24 release, so I'm afraid we won't have this even in -mm in the nearest months :( Sounds great ! (as for the delay, it wasn't the highest priority issue to begin with, so no worries). Ah.. coincidentally they are celebrated here, too, on the same time :D Merry Christmas and Happy New Year ! Oren. Thanks, Pavel Oren. The only thing that makes me keep wanting to go back to an LSM is the fact that the code defining the whitelist seems out of place in the vfs. But I guess that's actually separated into a modular cgroup, with the actual enforcement built in at the vfs. So that's really the best solution. -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Oren Laadan wrote: > > Serge E. Hallyn wrote: >> Quoting Pavel Emelyanov ([EMAIL PROTECTED]): >>> Oren Laadan wrote: Serge E. Hallyn wrote: > Quoting Oren Laadan ([EMAIL PROTECTED]): >> I hate to bring this again, but what if the admin in the container >> mounts an external file system (eg. nfs, usb, loop mount from a file, >> or via fuse), and that file system already has a device that we would >> like to ban inside that container ? > Miklos' user mount patches enforced that if !capable(CAP_MKNOD), > then mnt->mnt_flags |= MNT_NODEV. So that's no problem. Yes, that works to disallow all device files from a mounted file system. But it's a black and white thing: either they are all banned or allowed; you can't have some devices allowed and others not, depending on type A scenario where this may be useful is, for instance, if we some apps in the container to execute withing a pre-made chroot (sub)tree within that container. > But that's been pulled out of -mm! ? Crap. > >> Since anyway we will have to keep a white- (or black-) list of devices >> that are permitted in a container, and that list may change even change >> per container -- why not enforce the access control at the VFS layer ? >> It's safer in the long run. > By that you mean more along the lines of Pavel's patch than my whitelist > LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean > that > by 'vfs layer' :), or something different entirely? :) By 'vfs' I mean at open() time, and not at mount(), or mknod() time. Either yours or Pavel's; I tend to prefer not to use LSM as it may collide with future security modules. >>> Oren, AFAIS you've seen my patches for device access controller, right? > > If you mean this one: > http://openvz.org/pipermail/devel/2007-September/007647.html > then ack :) Great! Thanks. >>> Maybe we can revisit the issue then and try to come to agreement on what >>> kind of model and implementation we all want? >> That would be great, Pavel. I do prefer your solution over my LSM, so >> if we can get an elegant block device control right in the vfs code that >> would be my preference. > > I concur. > > So it seems to me that we are all in favor of the model where open() > of a device will consult a black/white-list. Also, we are all in favor > of a non-LSM implementation, Pavel's code being a good example. Thank you, Oren and Serge! I will revisit this issue then, but I have a vacation the next week and, after this, we have a New Year and Christmas holidays in Russia. So I will be able to go on with it only after the 7th January :( Hope this is OK for you. Besides, Andrew told that he would pay little attention to new features till the 2.6.24 release, so I'm afraid we won't have this even in -mm in the nearest months :( Thanks, Pavel > Oren. > >> The only thing that makes me keep wanting to go back to an LSM is the >> fact that the code defining the whitelist seems out of place in the vfs. >> But I guess that's actually separated into a modular cgroup, with the >> actual enforcement built in at the vfs. So that's really the best >> solution. >> >> -serge > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Serge E. Hallyn wrote: > Quoting Pavel Emelyanov ([EMAIL PROTECTED]): >> Oren Laadan wrote: >>> Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): > I hate to bring this again, but what if the admin in the container > mounts an external file system (eg. nfs, usb, loop mount from a file, > or via fuse), and that file system already has a device that we would > like to ban inside that container ? Miklos' user mount patches enforced that if !capable(CAP_MKNOD), then mnt->mnt_flags |= MNT_NODEV. So that's no problem. >>> Yes, that works to disallow all device files from a mounted file system. >>> >>> But it's a black and white thing: either they are all banned or allowed; >>> you can't have some devices allowed and others not, depending on type >>> A scenario where this may be useful is, for instance, if we some apps in >>> the container to execute withing a pre-made chroot (sub)tree within that >>> container. >>> But that's been pulled out of -mm! ? Crap. > Since anyway we will have to keep a white- (or black-) list of devices > that are permitted in a container, and that list may change even change > per container -- why not enforce the access control at the VFS layer ? > It's safer in the long run. By that you mean more along the lines of Pavel's patch than my whitelist LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that by 'vfs layer' :), or something different entirely? >>> :) >>> >>> By 'vfs' I mean at open() time, and not at mount(), or mknod() time. >>> Either yours or Pavel's; I tend to prefer not to use LSM as it may >>> collide with future security modules. >> Oren, AFAIS you've seen my patches for device access controller, right? If you mean this one: http://openvz.org/pipermail/devel/2007-September/007647.html then ack :) >> >> Maybe we can revisit the issue then and try to come to agreement on what >> kind of model and implementation we all want? > > That would be great, Pavel. I do prefer your solution over my LSM, so > if we can get an elegant block device control right in the vfs code that > would be my preference. I concur. So it seems to me that we are all in favor of the model where open() of a device will consult a black/white-list. Also, we are all in favor of a non-LSM implementation, Pavel's code being a good example. Oren. > The only thing that makes me keep wanting to go back to an LSM is the > fact that the code defining the whitelist seems out of place in the vfs. > But I guess that's actually separated into a modular cgroup, with the > actual enforcement built in at the vfs. So that's really the best > solution. > > -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Tetsuo Handa ([EMAIL PROTECTED]):
> A brief description about SYAORAN:
>
> SYAORAN stands for "Simple Yet All-important Object Realizing Abiding
> Nexus". SYAORAN is a filesystem for /dev with Mandatory Access Control.
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?
Maybe the fs will sell like hotcakes and everyone will know what SYAORAN
means by next year, but just in case that doesn't happen, there is
absolutely nothing in the name that would tell me I should bother to
look at it...
> /dev needs to be writable, but this means that files on /dev might be
> tampered with. SYAORAN can restrict combinations of (pathname, attribute)
> that the system can create. The attribute is one of directory, regular
> file, FIFO, UNIX domain socket, symbolic link, character or block device
> file with major/minor device numbers.
>
> SYAORAN can ensure /dev/null is a character device file with major=1 minor=3.
>
> Policy specifications for this filesystem is at
> http://tomoyo.sourceforge.jp/en/1.5.x/policy-syaoran.html
>
> 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.
> 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 +
> fs/syaoran/syaoran.h | 964
> +++
> 2 files changed, 1302 insertions(+)
>
> --- /dev/null
> +++ linux-2.6.24-rc5/fs/syaoran/syaoran.c
> @@ -0,0 +1,338 @@
> +/*
> + * fs/syaoran/syaoran.c
> + *
> + * Implementation of the Tamper-Proof Device Filesystem.
> + *
> + * Portions Copyright (C) 2005-2007 NTT DATA CORPORATION
> + *
> + * Version: 1.5.3-pre 2007/12/16
> + *
> + * This filesystem is developed using the ramfs implementation.
> + *
> + */
> +/*
> + * Resizable simple ram filesystem for Linux.
> + *
> + * Copyright (C) 2000 Linus Torvalds.
> + * 2000 Transmeta Corp.
> + *
> + * Usage limits added by David Gibson, Linuxcare Australia.
> + * This file is released under the GPL.
> + */
> +
> +/*
> + * NOTE! This filesystem is probably most useful
> + * not as a real filesystem, but as an example of
> + * how virtual filesystems can be written.
> + *
> + * It doesn't get much simpler than this. Consider
> + * that this file implements the full semantics of
> + * a POSIX-compliant read-write filesystem.
> + *
> + * Note in particular how the filesystem does not
> + * need to implement any data structures of its own
> + * to keep track of the virtual data: using the VFS
> + * caches is sufficient.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static struct super_operations syaoran_ops;
> +static struct address_space_operations syaoran_aops;
> +static struct inode_operations syaoran_file_inode_operations;
> +static struct inode_operations syaoran_dir_inode_operations;
> +static struct inode_operations syaoran_symlink_inode_operations;
> +static struct file_operations syaoran_file_operations;
> +
> +static struct backing_dev_info syaoran_backing_dev_info = {
> + .ra_pages = 0,/* No readahead */
> + .capabilities = BDI_CAP_NO_ACCT_DIRTY | BDI_CAP_NO_WRITEBACK |
> + BDI_CAP_MAP_DIRECT | BDI_CAP_MAP_COPY |
> + BDI_CAP_READ_MAP | BDI_CAP_WRITE_MAP | BDI_CAP_EXEC_MAP,
> +};
> +
> +#include "syaoran.h"
> +
> +static struct inode *syaoran_get_inode(struct super_block *sb, int mode,
> +dev_t dev)
> +{
> + struct inode *inode = new_inode(sb);
> +
> + if (inode) {
> + struct timespec now = CURRENT_TIME;
> + inode->i_mode = mode;
> + inode->i_uid = current->fsuid;
> + inode->i_gid = current->fsgid;
> + inode->i_blocks = 0;
> + inode->i_mapping->a_ops = _aops;
> + inode->i_mapping->backing_dev_info = _backing_dev_info;
> + inode->i_atime = now;
> + inode->i_mtime = now;
> + inode->i_ctime = now;
> + switch (mode & S_IFMT) {
> + default:
> + init_special_inode(inode, mode, dev);
> + if (S_ISBLK(mode))
> + inode->i_fop = _def_blk_fops;
> + else if (S_ISCHR(mode))
> + inode->i_fop = _def_chr_fops;
> + inode->i_op = _file_inode_operations;
> + break;
> + case S_IFREG:
> +
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Wed, 19 Dec 2007 21:11:11 +0900 Tetsuo Handa <[EMAIL PROTECTED]> wrote: > 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 will create inappropriate (i.e. filename with unexpected attributes) > device nodes, won't it? Yes. But root doesn't need access to these files, at least not usually. Create a separate user for editing config files - much lower probability of breakage. Remove almost all capabilities from root and profit. > After all, revoking CAP_MKNOD is not enough for guaranteeing > filename and its attributes. > > This filesystem is designed to guarantee filename and its attributes, > but this filesystem has additional access control capability. > You can forbid mknod/unlink /dev/null if you want nobody to do so. > You can forbid chmod/chown /dev/null if you want nobody to do so. You can forbid all operations on /dev (except udev) with an ACL. So, what is the need for this filesystem? signature.asc Description: PGP signature
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Oren Laadan ([EMAIL PROTECTED]): > > Serge E. Hallyn wrote: > > Quoting Oren Laadan ([EMAIL PROTECTED]): > >> I hate to bring this again, but what if the admin in the container > >> mounts an external file system (eg. nfs, usb, loop mount from a file, > >> or via fuse), and that file system already has a device that we would > >> like to ban inside that container ? > > > > Miklos' user mount patches enforced that if !capable(CAP_MKNOD), > > then mnt->mnt_flags |= MNT_NODEV. So that's no problem. > > Yes, that works to disallow all device files from a mounted file system. > > But it's a black and white thing: either they are all banned or allowed; > you can't have some devices allowed and others not, depending on type > A scenario where this may be useful is, for instance, if we some apps in > the container to execute withing a pre-made chroot (sub)tree within that > container. Yes, it's workable short-term, and we've always said that a more complete solution would be worked on later, as people have time. > > But that's been pulled out of -mm! ? Crap. > > > >> Since anyway we will have to keep a white- (or black-) list of devices > >> that are permitted in a container, and that list may change even change > >> per container -- why not enforce the access control at the VFS layer ? > >> It's safer in the long run. > > > > By that you mean more along the lines of Pavel's patch than my whitelist > > LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that > > by 'vfs layer' :), or something different entirely? > > :) > > By 'vfs' I mean at open() time, and not at mount(), or mknod() time. > Either yours or Pavel's; I tend to prefer not to use LSM as it may > collide with future security modules. Yeah I keep waffling. The LSM is so simple... but i do prefer Pavel's patch. Let's keep pursuing that. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Pavel Emelyanov ([EMAIL PROTECTED]): > Oren Laadan wrote: > > Serge E. Hallyn wrote: > >> Quoting Oren Laadan ([EMAIL PROTECTED]): > >>> I hate to bring this again, but what if the admin in the container > >>> mounts an external file system (eg. nfs, usb, loop mount from a file, > >>> or via fuse), and that file system already has a device that we would > >>> like to ban inside that container ? > >> Miklos' user mount patches enforced that if !capable(CAP_MKNOD), > >> then mnt->mnt_flags |= MNT_NODEV. So that's no problem. > > > > Yes, that works to disallow all device files from a mounted file system. > > > > But it's a black and white thing: either they are all banned or allowed; > > you can't have some devices allowed and others not, depending on type > > A scenario where this may be useful is, for instance, if we some apps in > > the container to execute withing a pre-made chroot (sub)tree within that > > container. > > > >> But that's been pulled out of -mm! ? Crap. > >> > >>> Since anyway we will have to keep a white- (or black-) list of devices > >>> that are permitted in a container, and that list may change even change > >>> per container -- why not enforce the access control at the VFS layer ? > >>> It's safer in the long run. > >> By that you mean more along the lines of Pavel's patch than my whitelist > >> LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that > >> by 'vfs layer' :), or something different entirely? > > > > :) > > > > By 'vfs' I mean at open() time, and not at mount(), or mknod() time. > > Either yours or Pavel's; I tend to prefer not to use LSM as it may > > collide with future security modules. > > Oren, AFAIS you've seen my patches for device access controller, right? > > Maybe we can revisit the issue then and try to come to agreement on what > kind of model and implementation we all want? That would be great, Pavel. I do prefer your solution over my LSM, so if we can get an elegant block device control right in the vfs code that would be my preference. The only thing that makes me keep wanting to go back to an LSM is the fact that the code defining the whitelist seems out of place in the vfs. But I guess that's actually separated into a modular cgroup, with the actual enforcement built in at the vfs. So that's really the best solution. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 will create inappropriate (i.e. filename with unexpected attributes) device nodes, won't it? Also, creating device nodes is not the only threat. The root can do # mv /dev/sda1 /dev/tmp; mv /dev/sda2 /dev/sda1; mv /dev/tmp /dev/sda2 to rename/unlink device nodes. After all, revoking CAP_MKNOD is not enough for guaranteeing filename and its attributes. This filesystem is designed to guarantee filename and its attributes, but this filesystem has additional access control capability. You can forbid mknod/unlink /dev/null if you want nobody to do so. You can forbid chmod/chown /dev/null if you want nobody to do so. Well... it is not fair to refer only udev's configuration file. If configuration file of this filesystem is tampered, this filesystem will create inappropriate device nodes. So, some access control mechanism for protecting configuration files is recommended for both udev and this filesystem. Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Oren Laadan wrote: > Serge E. Hallyn wrote: >> Quoting Oren Laadan ([EMAIL PROTECTED]): >>> I hate to bring this again, but what if the admin in the container >>> mounts an external file system (eg. nfs, usb, loop mount from a file, >>> or via fuse), and that file system already has a device that we would >>> like to ban inside that container ? >> Miklos' user mount patches enforced that if !capable(CAP_MKNOD), >> then mnt->mnt_flags |= MNT_NODEV. So that's no problem. > > Yes, that works to disallow all device files from a mounted file system. > > But it's a black and white thing: either they are all banned or allowed; > you can't have some devices allowed and others not, depending on type > A scenario where this may be useful is, for instance, if we some apps in > the container to execute withing a pre-made chroot (sub)tree within that > container. > >> But that's been pulled out of -mm! ? Crap. >> >>> Since anyway we will have to keep a white- (or black-) list of devices >>> that are permitted in a container, and that list may change even change >>> per container -- why not enforce the access control at the VFS layer ? >>> It's safer in the long run. >> By that you mean more along the lines of Pavel's patch than my whitelist >> LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that >> by 'vfs layer' :), or something different entirely? > > :) > > By 'vfs' I mean at open() time, and not at mount(), or mknod() time. > Either yours or Pavel's; I tend to prefer not to use LSM as it may > collide with future security modules. Oren, AFAIS you've seen my patches for device access controller, right? Maybe we can revisit the issue then and try to come to agreement on what kind of model and implementation we all want? > Oren. > >> thanks, >> -serge > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): I hate to bring this again, but what if the admin in the container mounts an external file system (eg. nfs, usb, loop mount from a file, or via fuse), and that file system already has a device that we would like to ban inside that container ? Miklos' user mount patches enforced that if !capable(CAP_MKNOD), then mnt-mnt_flags |= MNT_NODEV. So that's no problem. Yes, that works to disallow all device files from a mounted file system. But it's a black and white thing: either they are all banned or allowed; you can't have some devices allowed and others not, depending on type A scenario where this may be useful is, for instance, if we some apps in the container to execute withing a pre-made chroot (sub)tree within that container. But that's been pulled out of -mm! ? Crap. Since anyway we will have to keep a white- (or black-) list of devices that are permitted in a container, and that list may change even change per container -- why not enforce the access control at the VFS layer ? It's safer in the long run. By that you mean more along the lines of Pavel's patch than my whitelist LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that by 'vfs layer' :), or something different entirely? :) By 'vfs' I mean at open() time, and not at mount(), or mknod() time. Either yours or Pavel's; I tend to prefer not to use LSM as it may collide with future security modules. Oren, AFAIS you've seen my patches for device access controller, right? Maybe we can revisit the issue then and try to come to agreement on what kind of model and implementation we all want? Oren. thanks, -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 will create inappropriate (i.e. filename with unexpected attributes) device nodes, won't it? Also, creating device nodes is not the only threat. The root can do # mv /dev/sda1 /dev/tmp; mv /dev/sda2 /dev/sda1; mv /dev/tmp /dev/sda2 to rename/unlink device nodes. After all, revoking CAP_MKNOD is not enough for guaranteeing filename and its attributes. This filesystem is designed to guarantee filename and its attributes, but this filesystem has additional access control capability. You can forbid mknod/unlink /dev/null if you want nobody to do so. You can forbid chmod/chown /dev/null if you want nobody to do so. Well... it is not fair to refer only udev's configuration file. If configuration file of this filesystem is tampered, this filesystem will create inappropriate device nodes. So, some access control mechanism for protecting configuration files is recommended for both udev and this filesystem. Regards. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Pavel Emelyanov ([EMAIL PROTECTED]): Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): I hate to bring this again, but what if the admin in the container mounts an external file system (eg. nfs, usb, loop mount from a file, or via fuse), and that file system already has a device that we would like to ban inside that container ? Miklos' user mount patches enforced that if !capable(CAP_MKNOD), then mnt-mnt_flags |= MNT_NODEV. So that's no problem. Yes, that works to disallow all device files from a mounted file system. But it's a black and white thing: either they are all banned or allowed; you can't have some devices allowed and others not, depending on type A scenario where this may be useful is, for instance, if we some apps in the container to execute withing a pre-made chroot (sub)tree within that container. But that's been pulled out of -mm! ? Crap. Since anyway we will have to keep a white- (or black-) list of devices that are permitted in a container, and that list may change even change per container -- why not enforce the access control at the VFS layer ? It's safer in the long run. By that you mean more along the lines of Pavel's patch than my whitelist LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that by 'vfs layer' :), or something different entirely? :) By 'vfs' I mean at open() time, and not at mount(), or mknod() time. Either yours or Pavel's; I tend to prefer not to use LSM as it may collide with future security modules. Oren, AFAIS you've seen my patches for device access controller, right? Maybe we can revisit the issue then and try to come to agreement on what kind of model and implementation we all want? That would be great, Pavel. I do prefer your solution over my LSM, so if we can get an elegant block device control right in the vfs code that would be my preference. The only thing that makes me keep wanting to go back to an LSM is the fact that the code defining the whitelist seems out of place in the vfs. But I guess that's actually separated into a modular cgroup, with the actual enforcement built in at the vfs. So that's really the best solution. -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Oren Laadan ([EMAIL PROTECTED]): Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): I hate to bring this again, but what if the admin in the container mounts an external file system (eg. nfs, usb, loop mount from a file, or via fuse), and that file system already has a device that we would like to ban inside that container ? Miklos' user mount patches enforced that if !capable(CAP_MKNOD), then mnt-mnt_flags |= MNT_NODEV. So that's no problem. Yes, that works to disallow all device files from a mounted file system. But it's a black and white thing: either they are all banned or allowed; you can't have some devices allowed and others not, depending on type A scenario where this may be useful is, for instance, if we some apps in the container to execute withing a pre-made chroot (sub)tree within that container. Yes, it's workable short-term, and we've always said that a more complete solution would be worked on later, as people have time. But that's been pulled out of -mm! ? Crap. Since anyway we will have to keep a white- (or black-) list of devices that are permitted in a container, and that list may change even change per container -- why not enforce the access control at the VFS layer ? It's safer in the long run. By that you mean more along the lines of Pavel's patch than my whitelist LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that by 'vfs layer' :), or something different entirely? :) By 'vfs' I mean at open() time, and not at mount(), or mknod() time. Either yours or Pavel's; I tend to prefer not to use LSM as it may collide with future security modules. Yeah I keep waffling. The LSM is so simple... but i do prefer Pavel's patch. Let's keep pursuing that. -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Wed, 19 Dec 2007 21:11:11 +0900 Tetsuo Handa [EMAIL PROTECTED] wrote: 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 will create inappropriate (i.e. filename with unexpected attributes) device nodes, won't it? Yes. But root doesn't need access to these files, at least not usually. Create a separate user for editing config files - much lower probability of breakage. Remove almost all capabilities from root and profit. After all, revoking CAP_MKNOD is not enough for guaranteeing filename and its attributes. This filesystem is designed to guarantee filename and its attributes, but this filesystem has additional access control capability. You can forbid mknod/unlink /dev/null if you want nobody to do so. You can forbid chmod/chown /dev/null if you want nobody to do so. You can forbid all operations on /dev (except udev) with an ACL. So, what is the need for this filesystem? signature.asc Description: PGP signature
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Tetsuo Handa ([EMAIL PROTECTED]):
A brief description about SYAORAN:
SYAORAN stands for Simple Yet All-important Object Realizing Abiding
Nexus. SYAORAN is a filesystem for /dev with Mandatory Access Control.
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?
Maybe the fs will sell like hotcakes and everyone will know what SYAORAN
means by next year, but just in case that doesn't happen, there is
absolutely nothing in the name that would tell me I should bother to
look at it...
/dev needs to be writable, but this means that files on /dev might be
tampered with. SYAORAN can restrict combinations of (pathname, attribute)
that the system can create. The attribute is one of directory, regular
file, FIFO, UNIX domain socket, symbolic link, character or block device
file with major/minor device numbers.
SYAORAN can ensure /dev/null is a character device file with major=1 minor=3.
Policy specifications for this filesystem is at
http://tomoyo.sourceforge.jp/en/1.5.x/policy-syaoran.html
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.
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 +
fs/syaoran/syaoran.h | 964
+++
2 files changed, 1302 insertions(+)
--- /dev/null
+++ linux-2.6.24-rc5/fs/syaoran/syaoran.c
@@ -0,0 +1,338 @@
+/*
+ * fs/syaoran/syaoran.c
+ *
+ * Implementation of the Tamper-Proof Device Filesystem.
+ *
+ * Portions Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 1.5.3-pre 2007/12/16
+ *
+ * This filesystem is developed using the ramfs implementation.
+ *
+ */
+/*
+ * Resizable simple ram filesystem for Linux.
+ *
+ * Copyright (C) 2000 Linus Torvalds.
+ * 2000 Transmeta Corp.
+ *
+ * Usage limits added by David Gibson, Linuxcare Australia.
+ * This file is released under the GPL.
+ */
+
+/*
+ * NOTE! This filesystem is probably most useful
+ * not as a real filesystem, but as an example of
+ * how virtual filesystems can be written.
+ *
+ * It doesn't get much simpler than this. Consider
+ * that this file implements the full semantics of
+ * a POSIX-compliant read-write filesystem.
+ *
+ * Note in particular how the filesystem does not
+ * need to implement any data structures of its own
+ * to keep track of the virtual data: using the VFS
+ * caches is sufficient.
+ */
+
+#include linux/module.h
+#include linux/fs.h
+#include linux/pagemap.h
+#include linux/highmem.h
+#include linux/time.h
+#include linux/init.h
+#include linux/string.h
+#include linux/backing-dev.h
+#include linux/sched.h
+#include linux/uaccess.h
+
+static struct super_operations syaoran_ops;
+static struct address_space_operations syaoran_aops;
+static struct inode_operations syaoran_file_inode_operations;
+static struct inode_operations syaoran_dir_inode_operations;
+static struct inode_operations syaoran_symlink_inode_operations;
+static struct file_operations syaoran_file_operations;
+
+static struct backing_dev_info syaoran_backing_dev_info = {
+ .ra_pages = 0,/* No readahead */
+ .capabilities = BDI_CAP_NO_ACCT_DIRTY | BDI_CAP_NO_WRITEBACK |
+ BDI_CAP_MAP_DIRECT | BDI_CAP_MAP_COPY |
+ BDI_CAP_READ_MAP | BDI_CAP_WRITE_MAP | BDI_CAP_EXEC_MAP,
+};
+
+#include syaoran.h
+
+static struct inode *syaoran_get_inode(struct super_block *sb, int mode,
+dev_t dev)
+{
+ struct inode *inode = new_inode(sb);
+
+ if (inode) {
+ struct timespec now = CURRENT_TIME;
+ inode-i_mode = mode;
+ inode-i_uid = current-fsuid;
+ inode-i_gid = current-fsgid;
+ inode-i_blocks = 0;
+ inode-i_mapping-a_ops = syaoran_aops;
+ inode-i_mapping-backing_dev_info = syaoran_backing_dev_info;
+ inode-i_atime = now;
+ inode-i_mtime = now;
+ inode-i_ctime = now;
+ switch (mode S_IFMT) {
+ default:
+ init_special_inode(inode, mode, dev);
+ if (S_ISBLK(mode))
+ inode-i_fop = wrapped_def_blk_fops;
+ else if (S_ISCHR(mode))
+ inode-i_fop = wrapped_def_chr_fops;
+ inode-i_op = syaoran_file_inode_operations;
+ break;
+
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Serge E. Hallyn wrote: Quoting Pavel Emelyanov ([EMAIL PROTECTED]): Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): I hate to bring this again, but what if the admin in the container mounts an external file system (eg. nfs, usb, loop mount from a file, or via fuse), and that file system already has a device that we would like to ban inside that container ? Miklos' user mount patches enforced that if !capable(CAP_MKNOD), then mnt-mnt_flags |= MNT_NODEV. So that's no problem. Yes, that works to disallow all device files from a mounted file system. But it's a black and white thing: either they are all banned or allowed; you can't have some devices allowed and others not, depending on type A scenario where this may be useful is, for instance, if we some apps in the container to execute withing a pre-made chroot (sub)tree within that container. But that's been pulled out of -mm! ? Crap. Since anyway we will have to keep a white- (or black-) list of devices that are permitted in a container, and that list may change even change per container -- why not enforce the access control at the VFS layer ? It's safer in the long run. By that you mean more along the lines of Pavel's patch than my whitelist LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that by 'vfs layer' :), or something different entirely? :) By 'vfs' I mean at open() time, and not at mount(), or mknod() time. Either yours or Pavel's; I tend to prefer not to use LSM as it may collide with future security modules. Oren, AFAIS you've seen my patches for device access controller, right? If you mean this one: http://openvz.org/pipermail/devel/2007-September/007647.html then ack :) Maybe we can revisit the issue then and try to come to agreement on what kind of model and implementation we all want? That would be great, Pavel. I do prefer your solution over my LSM, so if we can get an elegant block device control right in the vfs code that would be my preference. I concur. So it seems to me that we are all in favor of the model where open() of a device will consult a black/white-list. Also, we are all in favor of a non-LSM implementation, Pavel's code being a good example. Oren. The only thing that makes me keep wanting to go back to an LSM is the fact that the code defining the whitelist seems out of place in the vfs. But I guess that's actually separated into a modular cgroup, with the actual enforcement built in at the vfs. So that's really the best solution. -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Pavel Emelyanov ([EMAIL PROTECTED]): Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): I hate to bring this again, but what if the admin in the container mounts an external file system (eg. nfs, usb, loop mount from a file, or via fuse), and that file system already has a device that we would like to ban inside that container ? Miklos' user mount patches enforced that if !capable(CAP_MKNOD), then mnt-mnt_flags |= MNT_NODEV. So that's no problem. Yes, that works to disallow all device files from a mounted file system. But it's a black and white thing: either they are all banned or allowed; you can't have some devices allowed and others not, depending on type A scenario where this may be useful is, for instance, if we some apps in the container to execute withing a pre-made chroot (sub)tree within that container. But that's been pulled out of -mm! ? Crap. Since anyway we will have to keep a white- (or black-) list of devices that are permitted in a container, and that list may change even change per container -- why not enforce the access control at the VFS layer ? It's safer in the long run. By that you mean more along the lines of Pavel's patch than my whitelist LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that by 'vfs layer' :), or something different entirely? :) By 'vfs' I mean at open() time, and not at mount(), or mknod() time. Either yours or Pavel's; I tend to prefer not to use LSM as it may collide with future security modules. Oren, AFAIS you've seen my patches for device access controller, right? If you mean this one: http://openvz.org/pipermail/devel/2007-September/007647.html then ack :) Great! Thanks. Maybe we can revisit the issue then and try to come to agreement on what kind of model and implementation we all want? That would be great, Pavel. I do prefer your solution over my LSM, so if we can get an elegant block device control right in the vfs code that would be my preference. I concur. So it seems to me that we are all in favor of the model where open() of a device will consult a black/white-list. Also, we are all in favor of a non-LSM implementation, Pavel's code being a good example. Thank you, Oren and Serge! I will revisit this issue then, but I have a vacation the next week and, after this, we have a New Year and Christmas holidays in Russia. So I will be able to go on with it only after the 7th January :( Hope this is OK for you. Besides, Andrew told that he would pay little attention to new features till the 2.6.24 release, so I'm afraid we won't have this even in -mm in the nearest months :( Thanks, Pavel Oren. The only thing that makes me keep wanting to go back to an LSM is the fact that the code defining the whitelist seems out of place in the vfs. But I guess that's actually separated into a modular cgroup, with the actual enforcement built in at the vfs. So that's really the best solution. -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
--- [EMAIL PROTECTED] wrote: > On Thu, 06 Dec 2007 15:29:07 GMT, Pavel Machek said: > > > > > Why not use SELinux? > > > > > > Because 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). > > > > Why not improve selinux to be able to assign label of new file based > > on directory label and name? > > The problem isn't the label, it's the *other* attributes... > > What happens if /dev/null has the correct SELinux label, but the major/minor > is 1,27 rather than 1,3? Isn't this the kind of thing that Bastille is good for? Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Thu, 06 Dec 2007 15:29:07 GMT, Pavel Machek said: > > > Why not use SELinux? > > > > Because 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). > > Why not improve selinux to be able to assign label of new file based > on directory label and name? The problem isn't the label, it's the *other* attributes... What happens if /dev/null has the correct SELinux label, but the major/minor is 1,27 rather than 1,3? pgpMfkMr9kbdI.pgp Description: PGP signature
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
> Why not use SELinux? > > Because 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). Why not improve selinux to be able to assign label of new file based on directory label and name? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Mon, 17 Dec 2007 16:30:54 +1030 David Newall <[EMAIL PROTECTED]> wrote: > Tetsuo Handa wrote: > > If Bob is malicious and creates /dev/sda1 with block-8-2 attribute [...] > > Bob can't do that. Only root can. Not even root can, if you remove him the capability. Only udev can. (which possibly doesn't have to run as root, given correct capability set?) Of course root may be able to change the configuration of udev to create device nodes of his liking if you allow that... signature.asc Description: PGP signature
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Mon, 17 Dec 2007 16:05:31 +0300 Al Boldi <[EMAIL PROTECTED]> wrote: > Indan Zupancic wrote: > > On Mon, December 17, 2007 01:40, Tetsuo Handa wrote: > > I think you can better spend your time on read-only bind mounts. > > That would be too coarse. > 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. (OTOH, both don't need CAP_SYS_ADMIN. Maybe udev needs CAP_SYS_MODULE...) Now, stopping people from faking hotplug events is totally another story. Is that currently possible? signature.asc Description: PGP signature
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Mon, 17 Dec 2007 16:05:31 +0300 Al Boldi [EMAIL PROTECTED] wrote: Indan Zupancic wrote: On Mon, December 17, 2007 01:40, Tetsuo Handa wrote: I think you can better spend your time on read-only bind mounts. That would be too coarse. 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. (OTOH, both don't need CAP_SYS_ADMIN. Maybe udev needs CAP_SYS_MODULE...) Now, stopping people from faking hotplug events is totally another story. Is that currently possible? signature.asc Description: PGP signature
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Mon, 17 Dec 2007 16:30:54 +1030 David Newall [EMAIL PROTECTED] wrote: Tetsuo Handa wrote: If Bob is malicious and creates /dev/sda1 with block-8-2 attribute [...] Bob can't do that. Only root can. Not even root can, if you remove him the capability. Only udev can. (which possibly doesn't have to run as root, given correct capability set?) Of course root may be able to change the configuration of udev to create device nodes of his liking if you allow that... signature.asc Description: PGP signature
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Why not use SELinux? Because 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). Why not improve selinux to be able to assign label of new file based on directory label and name? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Thu, 06 Dec 2007 15:29:07 GMT, Pavel Machek said: Why not use SELinux? Because 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). Why not improve selinux to be able to assign label of new file based on directory label and name? The problem isn't the label, it's the *other* attributes... What happens if /dev/null has the correct SELinux label, but the major/minor is 1,27 rather than 1,3? pgpMfkMr9kbdI.pgp Description: PGP signature
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
--- [EMAIL PROTECTED] wrote: On Thu, 06 Dec 2007 15:29:07 GMT, Pavel Machek said: Why not use SELinux? Because 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). Why not improve selinux to be able to assign label of new file based on directory label and name? The problem isn't the label, it's the *other* attributes... What happens if /dev/null has the correct SELinux label, but the major/minor is 1,27 rather than 1,3? Isn't this the kind of thing that Bastille is good for? Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 --bind /dev/hda1 /root/hda1 [EMAIL PROTECTED] ~]# ls -l /root/hda1 brw-r- 1 root disk 3, 1 Dec 18 2007 /root/hda1 Oh, surprising. I didn't know mount() accepts non-directory for mount-point. But I think this is not a mount operation because I can't see the contents of /dev/hda1 through /root/hda1 . Can I see the contents of /dev/hda1 through /root/hda1 ? > Then it sounds like this filesystem is something Tomoyo can use. I had / partition mounted for read-only so that the admin can't do 'mknod /root/hda1 b 3 1' in 2003, and I named it "Security Advancement Know-how Upon Readonly Approach for Linux" or SAKURA Linux. This filesystem (SYAORAN) is developed to make /dev writable and tamper-proof when / partition is read-only or protected by MAC. TOMOYO is a pathname-based MAC implementation, and SAKURA and SYAORAN were merged into TOMOYO Linux. ;-) Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Serge E. Hallyn wrote: > Quoting Oren Laadan ([EMAIL PROTECTED]): >> I hate to bring this again, but what if the admin in the container >> mounts an external file system (eg. nfs, usb, loop mount from a file, >> or via fuse), and that file system already has a device that we would >> like to ban inside that container ? > > Miklos' user mount patches enforced that if !capable(CAP_MKNOD), > then mnt->mnt_flags |= MNT_NODEV. So that's no problem. Yes, that works to disallow all device files from a mounted file system. But it's a black and white thing: either they are all banned or allowed; you can't have some devices allowed and others not, depending on type A scenario where this may be useful is, for instance, if we some apps in the container to execute withing a pre-made chroot (sub)tree within that container. > > But that's been pulled out of -mm! ? Crap. > >> Since anyway we will have to keep a white- (or black-) list of devices >> that are permitted in a container, and that list may change even change >> per container -- why not enforce the access control at the VFS layer ? >> It's safer in the long run. > > By that you mean more along the lines of Pavel's patch than my whitelist > LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that > by 'vfs layer' :), or something different entirely? :) By 'vfs' I mean at open() time, and not at mount(), or mknod() time. Either yours or Pavel's; I tend to prefer not to use LSM as it may collide with future security modules. Oren. > > thanks, > -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Tetsuo Handa ([EMAIL PROTECTED]): > 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 CAP_SYS_MOUNT process from doing > > mount --bind /dev/hda1 /dev/null ? > > Excuse me, but I guess you meant "mount --bind /dev/ /root/" or something > because mount operation requires directories. Nope, try touch /root/hda1 ls -l /root/hda1 mount --bind /dev/hda1 /root/hda1 ls -l /root/hda1 But I see tomoyo prevents that > MAC can prevent a rogue CAP_SYS_MOUNT process from doing > "mount --bind /dev/ /root/". > For example, regarding TOMOYO Linux, you need to give > "allow_mount /dev/ /root/ --bind 0" permission > to permit "mount --bind /dev/ /root/" request. Ok, that answers my question. Thanks. (I won't go into "who gets to say allow_mount" :) > Did you mean "ln -s /dev/hda1 /dev/null" or "ln /dev/hda1 /dev/null"? > No problem. MAC can prevent such requests too. Then it sounds like this filesystem is something Tomoyo can use. thanks, -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 CAP_SYS_MOUNT process from doing > mount --bind /dev/hda1 /dev/null ? Excuse me, but I guess you meant "mount --bind /dev/ /root/" or something because mount operation requires directories. MAC can prevent a rogue CAP_SYS_MOUNT process from doing "mount --bind /dev/ /root/". For example, regarding TOMOYO Linux, you need to give "allow_mount /dev/ /root/ --bind 0" permission to permit "mount --bind /dev/ /root/" request. Did you mean "ln -s /dev/hda1 /dev/null" or "ln /dev/hda1 /dev/null"? No problem. MAC can prevent such requests too. Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Oren Laadan ([EMAIL PROTECTED]): > > I hate to bring this again, but what if the admin in the container > mounts an external file system (eg. nfs, usb, loop mount from a file, > or via fuse), and that file system already has a device that we would > like to ban inside that container ? Miklos' user mount patches enforced that if !capable(CAP_MKNOD), then mnt->mnt_flags |= MNT_NODEV. So that's no problem. But that's been pulled out of -mm! ? Crap. > Since anyway we will have to keep a white- (or black-) list of devices > that are permitted in a container, and that list may change even change > per container -- why not enforce the access control at the VFS layer ? > It's safer in the long run. By that you mean more along the lines of Pavel's patch than my whitelist LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that by 'vfs layer' :), or something different entirely? thanks, -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Serge E. Hallyn ([EMAIL PROTECTED]): > Quoting Tetsuo Handa ([EMAIL PROTECTED]): > > 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). > > Sure but that doesn't bother us :) > > The admin in the container has his own /dev directory and can do what he > likes with the devices he's allowed to have. He just shouldn't have > access to others. If he wants to rename /dev/sda1 to /dev/sda5 that's > his choice. > > > > To use your approach, i guess we would have to use selinux (or tomoyo) > > > to enforce that devices may only be created under /dev? > > Everyone can use this filesystem alone. > > Sure but it is worthless alone. > > No? Oh, no, I'm sorry - I was thinking in terms of my requirements again. But your requirements are to ensure that an application accessing a device at a well-known location get what it expect. So then the main quesiton is still the one I think Al had asked - what keeps a rogue CAP_SYS_MOUNT process from doing mount --bind /dev/hda1 /dev/null ? thanks, -serge > What will keep the container admin from doing 'mknod /root/hda1 b 3 1'? > > > But use with MAC (or whatever access control mechanisms that prevent > > attackers from unmounting/overlaying this filesystem) is recomennded. > > -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
I hate to bring this again, but what if the admin in the container mounts an external file system (eg. nfs, usb, loop mount from a file, or via fuse), and that file system already has a device that we would like to ban inside that container ? Since anyway we will have to keep a white- (or black-) list of devices that are permitted in a container, and that list may change even change per container -- why not enforce the access control at the VFS layer ? It's safer in the long run. Oren. Serge E. Hallyn wrote: > Quoting Tetsuo Handa ([EMAIL PROTECTED]): >> 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). > > Sure but that doesn't bother us :) > > The admin in the container has his own /dev directory and can do what he > likes with the devices he's allowed to have. He just shouldn't have > access to others. If he wants to rename /dev/sda1 to /dev/sda5 that's > his choice. > >>> To use your approach, i guess we would have to use selinux (or tomoyo) >>> to enforce that devices may only be created under /dev? >> Everyone can use this filesystem alone. > > Sure but it is worthless alone. > > No? > > What will keep the container admin from doing 'mknod /root/hda1 b 3 1'? > >> But use with MAC (or whatever access control mechanisms that prevent >> attackers from unmounting/overlaying this filesystem) is recomennded. > > -serge > ___ > Containers mailing list > [EMAIL PROTECTED] > https://lists.linux-foundation.org/mailman/listinfo/containers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Tetsuo Handa ([EMAIL PROTECTED]): > 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). Sure but that doesn't bother us :) The admin in the container has his own /dev directory and can do what he likes with the devices he's allowed to have. He just shouldn't have access to others. If he wants to rename /dev/sda1 to /dev/sda5 that's his choice. > > To use your approach, i guess we would have to use selinux (or tomoyo) > > to enforce that devices may only be created under /dev? > Everyone can use this filesystem alone. Sure but it is worthless alone. No? What will keep the container admin from doing 'mknod /root/hda1 b 3 1'? > But use with MAC (or whatever access control mechanisms that prevent > attackers from unmounting/overlaying this filesystem) is recomennded. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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) > to enforce that devices may only be created under /dev? Everyone can use this filesystem alone. But use with MAC (or whatever access control mechanisms that prevent attackers from unmounting/overlaying this filesystem) is recomennded. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Tetsuo Handa ([EMAIL PROTECTED]): > A brief description about SYAORAN: > > SYAORAN stands for "Simple Yet All-important Object Realizing Abiding > Nexus". SYAORAN is a filesystem for /dev with Mandatory Access Control. > > /dev needs to be writable, but this means that files on /dev might be > tampered with. SYAORAN can restrict combinations of (pathname, attribute) > that the system can create. The attribute is one of directory, regular > file, FIFO, UNIX domain socket, symbolic link, character or block device > file with major/minor device numbers. > > SYAORAN can ensure /dev/null is a character device file with major=1 minor=3. > > Policy specifications for this filesystem is at > http://tomoyo.sourceforge.jp/en/1.5.x/policy-syaoran.html > > 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. > 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). We need something similar for system containers (like vservers). We will likely want root in a container to be confined to a certain set of devices. For starters we expect to use the capability bounding sets (see http://lkml.org/lkml/2007/11/26/206). So a container will have a static /dev predefined, and CAP_MKNOD will be removed from its capability bounding set so that root in a container cannot create any more new devices. For future more sophisticated device controls, two similar approaches have been suggested (one by me, see https://lists.linux-foundation.org/pipermail/containers/2007-September/007423.html and https://lists.linux-foundation.org/pipermail/containers/2007-November/008589.html ). Both actually control the devices a process can create period, rather than trying to control at the filesystem. And yes, these both lack the feature in your solution that for instance 'c 1 3' must be called null, which appears to be the kind of guarantee apparmor likes to provide. To use your approach, i guess we would have to use selinux (or tomoyo) to enforce that devices may only be created under /dev? -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
( 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 other administrators from logging in. If your defense strategy > involves trying to enumerate all of those possible ways and then shut > them down one by one, you're relying upon a defense strategy known as > "blacklisting". Blacklisting has a terrible track record in the > security field, because it's too easy to overlook one pathway. Of course, I assume whitelisting. SELinux and TOMOYO Linux and many other MAC implementations uses whitelisting approach, and this filesystem is whiltelisting approach. This filesystem handles what MAC implementations don't handle. In other words, it is a remaining hole. I'm proposing: Don't you think it is dangerous to assume files in /dev directory have appropriate filename and attributes binding? MAC can restrict processes who can create files in /dev directory, but MAC doesn't enforce filename and attributes binding. So, how about enforcing filename and attributes binding in filesystem layer? Regards. To David Wagner: Could you please Cc: me so that I can reply to your message? I can't reply to your message since I'm reading this ml in daily digest mode. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 with TOMOYO Linux, but this filesystem can be used with other MAC implementations too. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Indan Zupancic wrote: > On Mon, December 17, 2007 01:40, Tetsuo Handa wrote: > > So, use of this filesystem alone is meaningless because > > attackers with root privileges can do what you are saying. > > But use of this filesystem with MAC is still valid because > > MAC can prevent attackers with root privileges from doing what you are > > saying. > > If MAC can avoid all that, then why can't it also avoid tampering with > /dev? What security does your filesystem add at all, if it's useless > without a MAC doing all the hard work? 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. > I think you can better spend your time on read-only bind mounts. That would be too coarse. Thanks! -- Al -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 foo_t to create block device file in dev_t directory". TOMOYO's granularity is "allow foo to create block device file named /dev/sda1". Both don't enforce filename and its attributes pair, thus the attacker with root privilege can create fake device files if he/she is permitted to create device files by MAC's policy. It would be possible to handle this pair within MAC's policy by expanding their policy syntaxes, but offloading this handling on filesystem can make MAC's policy syntax simple because filename and its attributes pairs are conventionally constant. You won't let foo_t to create /dev/sda1 with block-8-1 attributes and let bar_t to create /dev/sda1 with block-8-2 attributes, will you? You don't want to describe attribute information to every entry in MAC's policy, do you? It is redundant to describe this attribute enforcement information in MAC's policy unless you want to break conventional filename and its attributes pairs. > What security does your filesystem add at all, if it's useless without a MAC > doing all the hard work? Allow / partition to be mounted for read-only mode. Allow /dev partition to be enforced filename and its attributes to avoid /dev/null spoofing (create /dev/null as a regular file for eavesdropping purpose). This filesystem adds filename and its attributes enforcement, but it is overridable if this filesystem is used without MAC. This filesystem adds unoverridable filename and its attributes enforcement if this filesystem is used with MAC. Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Hi, On Mon, December 17, 2007 01:40, Tetsuo Handa wrote: > 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 plenty of ways to prevent an administrator >> from logging in, e.g. using iptables or changing the password. > MAC mediates execution of /sbin/iptables or /usr/bin/passwd . > > So, use of this filesystem alone is meaningless because > attackers with root privileges can do what you are saying. > But use of this filesystem with MAC is still valid because > MAC can prevent attackers with root privileges from doing what you are saying. If MAC can avoid all that, then why can't it also avoid tampering with /dev? What security does your filesystem add at all, if it's useless without a MAC doing all the hard work? I think you can better spend your time on read-only bind mounts. Greetings, Indan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
David Wagner wrote: > If the attacker gets full administrator-level access on your machine, > there are a gazillion ways the attacker can prevent other admins from > logging on. This patch can't prevent that. It sounds like this patch > is trying to solve a fundamentally unsolveable problem. Tetsuo Handa wrote: > Please be aware that I'm saying "if this filesystem is used with MAC". I'm aware. I'm sticking with my argument. I doubt that any we're likely to see a MAC system that is strict enough to prevent an attacker with administrator access from locking out other admins, and is yet is loose enough to be useful in practice. I think the proposed patch is like sticking a thumb in the dike and is trying to solve a problem that cannot be solved with any reasonable application of effort. I think if the attacker has gotten administrator level, then we'll never be able to prevent the attacker from doing all sorts of bad things we don't like, like locking out other admins. Of course if we have a proposed defense that only stops one particular attack pathway but leaves dozens others open, it's always convenient to say that "the other attack pathways aren't my problem, that's the MAC's business". Sure, if we want to hypothesize the existence of a "magic fairy dust" MAC system that somehow closes every other path via which admin-level attackers could lock out other admins, except for this one pathway, then this patch might make sense. But I see no reason to expect ordinary MAC systems to have that property. Trying to put in place a defense that only prevents on particular attack path, when there are a thousand other ways an attacker might achieve the same ends, does not seem like a good way to go about securing your system. For every one attack path that you shut down, the attacker can probably think up a dozen new paths that you haven't shut down yet. That isn't a good basis for security. Personally, I'd argue that we should learn a different lesson from the attack you experienced. The lesson is not "oh boy, we better shut down this particular way that the attacker misused administrator-level access". I think a better lesson is "let's think about ways to reduce the likelihood that attackers will get administrator-level access, because once the attacker has administrator-level access, the attacker can do a lot of harm". >If MAC(such as SELinux, TOMOYO Linux) allows attackers to >"mount other filesystem over this filesystem", this filesystem is no >longer tamper-proof. >But as long as MAC prevents attackers from mounting other filesystem >over this filesystem, >this filesystem can remain tamper-proof. 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 other administrators from logging in. If your defense strategy involves trying to enumerate all of those possible ways and then shut them down one by one, you're relying upon a defense strategy known as "blacklisting". Blacklisting has a terrible track record in the security field, because it's too easy to overlook one pathway. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
David Wagner wrote: If the attacker gets full administrator-level access on your machine, there are a gazillion ways the attacker can prevent other admins from logging on. This patch can't prevent that. It sounds like this patch is trying to solve a fundamentally unsolveable problem. Tetsuo Handa wrote: Please be aware that I'm saying if this filesystem is used with MAC. I'm aware. I'm sticking with my argument. I doubt that any we're likely to see a MAC system that is strict enough to prevent an attacker with administrator access from locking out other admins, and is yet is loose enough to be useful in practice. I think the proposed patch is like sticking a thumb in the dike and is trying to solve a problem that cannot be solved with any reasonable application of effort. I think if the attacker has gotten administrator level, then we'll never be able to prevent the attacker from doing all sorts of bad things we don't like, like locking out other admins. Of course if we have a proposed defense that only stops one particular attack pathway but leaves dozens others open, it's always convenient to say that the other attack pathways aren't my problem, that's the MAC's business. Sure, if we want to hypothesize the existence of a magic fairy dust MAC system that somehow closes every other path via which admin-level attackers could lock out other admins, except for this one pathway, then this patch might make sense. But I see no reason to expect ordinary MAC systems to have that property. Trying to put in place a defense that only prevents on particular attack path, when there are a thousand other ways an attacker might achieve the same ends, does not seem like a good way to go about securing your system. For every one attack path that you shut down, the attacker can probably think up a dozen new paths that you haven't shut down yet. That isn't a good basis for security. Personally, I'd argue that we should learn a different lesson from the attack you experienced. The lesson is not oh boy, we better shut down this particular way that the attacker misused administrator-level access. I think a better lesson is let's think about ways to reduce the likelihood that attackers will get administrator-level access, because once the attacker has administrator-level access, the attacker can do a lot of harm. If MAC(such as SELinux, TOMOYO Linux) allows attackers to mount other filesystem over this filesystem, this filesystem is no longer tamper-proof. But as long as MAC prevents attackers from mounting other filesystem over this filesystem, this filesystem can remain tamper-proof. 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 other administrators from logging in. If your defense strategy involves trying to enumerate all of those possible ways and then shut them down one by one, you're relying upon a defense strategy known as blacklisting. Blacklisting has a terrible track record in the security field, because it's too easy to overlook one pathway. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Hi, On Mon, December 17, 2007 01:40, Tetsuo Handa wrote: 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 plenty of ways to prevent an administrator from logging in, e.g. using iptables or changing the password. MAC mediates execution of /sbin/iptables or /usr/bin/passwd . So, use of this filesystem alone is meaningless because attackers with root privileges can do what you are saying. But use of this filesystem with MAC is still valid because MAC can prevent attackers with root privileges from doing what you are saying. If MAC can avoid all that, then why can't it also avoid tampering with /dev? What security does your filesystem add at all, if it's useless without a MAC doing all the hard work? I think you can better spend your time on read-only bind mounts. Greetings, Indan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 foo_t to create block device file in dev_t directory. TOMOYO's granularity is allow foo to create block device file named /dev/sda1. Both don't enforce filename and its attributes pair, thus the attacker with root privilege can create fake device files if he/she is permitted to create device files by MAC's policy. It would be possible to handle this pair within MAC's policy by expanding their policy syntaxes, but offloading this handling on filesystem can make MAC's policy syntax simple because filename and its attributes pairs are conventionally constant. You won't let foo_t to create /dev/sda1 with block-8-1 attributes and let bar_t to create /dev/sda1 with block-8-2 attributes, will you? You don't want to describe attribute information to every entry in MAC's policy, do you? It is redundant to describe this attribute enforcement information in MAC's policy unless you want to break conventional filename and its attributes pairs. What security does your filesystem add at all, if it's useless without a MAC doing all the hard work? Allow / partition to be mounted for read-only mode. Allow /dev partition to be enforced filename and its attributes to avoid /dev/null spoofing (create /dev/null as a regular file for eavesdropping purpose). This filesystem adds filename and its attributes enforcement, but it is overridable if this filesystem is used without MAC. This filesystem adds unoverridable filename and its attributes enforcement if this filesystem is used with MAC. Regards. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Indan Zupancic wrote: On Mon, December 17, 2007 01:40, Tetsuo Handa wrote: So, use of this filesystem alone is meaningless because attackers with root privileges can do what you are saying. But use of this filesystem with MAC is still valid because MAC can prevent attackers with root privileges from doing what you are saying. If MAC can avoid all that, then why can't it also avoid tampering with /dev? What security does your filesystem add at all, if it's useless without a MAC doing all the hard work? 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. I think you can better spend your time on read-only bind mounts. That would be too coarse. Thanks! -- Al -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 with TOMOYO Linux, but this filesystem can be used with other MAC implementations too. Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
( 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 other administrators from logging in. If your defense strategy involves trying to enumerate all of those possible ways and then shut them down one by one, you're relying upon a defense strategy known as blacklisting. Blacklisting has a terrible track record in the security field, because it's too easy to overlook one pathway. Of course, I assume whitelisting. SELinux and TOMOYO Linux and many other MAC implementations uses whitelisting approach, and this filesystem is whiltelisting approach. This filesystem handles what MAC implementations don't handle. In other words, it is a remaining hole. I'm proposing: Don't you think it is dangerous to assume files in /dev directory have appropriate filename and attributes binding? MAC can restrict processes who can create files in /dev directory, but MAC doesn't enforce filename and attributes binding. So, how about enforcing filename and attributes binding in filesystem layer? Regards. To David Wagner: Could you please Cc: me so that I can reply to your message? I can't reply to your message since I'm reading this ml in daily digest mode. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Tetsuo Handa ([EMAIL PROTECTED]): A brief description about SYAORAN: SYAORAN stands for Simple Yet All-important Object Realizing Abiding Nexus. SYAORAN is a filesystem for /dev with Mandatory Access Control. /dev needs to be writable, but this means that files on /dev might be tampered with. SYAORAN can restrict combinations of (pathname, attribute) that the system can create. The attribute is one of directory, regular file, FIFO, UNIX domain socket, symbolic link, character or block device file with major/minor device numbers. SYAORAN can ensure /dev/null is a character device file with major=1 minor=3. Policy specifications for this filesystem is at http://tomoyo.sourceforge.jp/en/1.5.x/policy-syaoran.html 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. 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). We need something similar for system containers (like vservers). We will likely want root in a container to be confined to a certain set of devices. For starters we expect to use the capability bounding sets (see http://lkml.org/lkml/2007/11/26/206). So a container will have a static /dev predefined, and CAP_MKNOD will be removed from its capability bounding set so that root in a container cannot create any more new devices. For future more sophisticated device controls, two similar approaches have been suggested (one by me, see https://lists.linux-foundation.org/pipermail/containers/2007-September/007423.html and https://lists.linux-foundation.org/pipermail/containers/2007-November/008589.html ). Both actually control the devices a process can create period, rather than trying to control at the filesystem. And yes, these both lack the feature in your solution that for instance 'c 1 3' must be called null, which appears to be the kind of guarantee apparmor likes to provide. To use your approach, i guess we would have to use selinux (or tomoyo) to enforce that devices may only be created under /dev? -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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) to enforce that devices may only be created under /dev? Everyone can use this filesystem alone. But use with MAC (or whatever access control mechanisms that prevent attackers from unmounting/overlaying this filesystem) is recomennded. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Tetsuo Handa ([EMAIL PROTECTED]): 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). Sure but that doesn't bother us :) The admin in the container has his own /dev directory and can do what he likes with the devices he's allowed to have. He just shouldn't have access to others. If he wants to rename /dev/sda1 to /dev/sda5 that's his choice. To use your approach, i guess we would have to use selinux (or tomoyo) to enforce that devices may only be created under /dev? Everyone can use this filesystem alone. Sure but it is worthless alone. No? What will keep the container admin from doing 'mknod /root/hda1 b 3 1'? But use with MAC (or whatever access control mechanisms that prevent attackers from unmounting/overlaying this filesystem) is recomennded. -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
I hate to bring this again, but what if the admin in the container mounts an external file system (eg. nfs, usb, loop mount from a file, or via fuse), and that file system already has a device that we would like to ban inside that container ? Since anyway we will have to keep a white- (or black-) list of devices that are permitted in a container, and that list may change even change per container -- why not enforce the access control at the VFS layer ? It's safer in the long run. Oren. Serge E. Hallyn wrote: Quoting Tetsuo Handa ([EMAIL PROTECTED]): 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). Sure but that doesn't bother us :) The admin in the container has his own /dev directory and can do what he likes with the devices he's allowed to have. He just shouldn't have access to others. If he wants to rename /dev/sda1 to /dev/sda5 that's his choice. To use your approach, i guess we would have to use selinux (or tomoyo) to enforce that devices may only be created under /dev? Everyone can use this filesystem alone. Sure but it is worthless alone. No? What will keep the container admin from doing 'mknod /root/hda1 b 3 1'? But use with MAC (or whatever access control mechanisms that prevent attackers from unmounting/overlaying this filesystem) is recomennded. -serge ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Serge E. Hallyn ([EMAIL PROTECTED]): Quoting Tetsuo Handa ([EMAIL PROTECTED]): 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). Sure but that doesn't bother us :) The admin in the container has his own /dev directory and can do what he likes with the devices he's allowed to have. He just shouldn't have access to others. If he wants to rename /dev/sda1 to /dev/sda5 that's his choice. To use your approach, i guess we would have to use selinux (or tomoyo) to enforce that devices may only be created under /dev? Everyone can use this filesystem alone. Sure but it is worthless alone. No? Oh, no, I'm sorry - I was thinking in terms of my requirements again. But your requirements are to ensure that an application accessing a device at a well-known location get what it expect. So then the main quesiton is still the one I think Al had asked - what keeps a rogue CAP_SYS_MOUNT process from doing mount --bind /dev/hda1 /dev/null ? thanks, -serge What will keep the container admin from doing 'mknod /root/hda1 b 3 1'? But use with MAC (or whatever access control mechanisms that prevent attackers from unmounting/overlaying this filesystem) is recomennded. -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Oren Laadan ([EMAIL PROTECTED]): I hate to bring this again, but what if the admin in the container mounts an external file system (eg. nfs, usb, loop mount from a file, or via fuse), and that file system already has a device that we would like to ban inside that container ? Miklos' user mount patches enforced that if !capable(CAP_MKNOD), then mnt-mnt_flags |= MNT_NODEV. So that's no problem. But that's been pulled out of -mm! ? Crap. Since anyway we will have to keep a white- (or black-) list of devices that are permitted in a container, and that list may change even change per container -- why not enforce the access control at the VFS layer ? It's safer in the long run. By that you mean more along the lines of Pavel's patch than my whitelist LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that by 'vfs layer' :), or something different entirely? thanks, -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 CAP_SYS_MOUNT process from doing mount --bind /dev/hda1 /dev/null ? Excuse me, but I guess you meant mount --bind /dev/ /root/ or something because mount operation requires directories. MAC can prevent a rogue CAP_SYS_MOUNT process from doing mount --bind /dev/ /root/. For example, regarding TOMOYO Linux, you need to give allow_mount /dev/ /root/ --bind 0 permission to permit mount --bind /dev/ /root/ request. Did you mean ln -s /dev/hda1 /dev/null or ln /dev/hda1 /dev/null? No problem. MAC can prevent such requests too. Regards. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Quoting Tetsuo Handa ([EMAIL PROTECTED]): 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 CAP_SYS_MOUNT process from doing mount --bind /dev/hda1 /dev/null ? Excuse me, but I guess you meant mount --bind /dev/ /root/ or something because mount operation requires directories. Nope, try touch /root/hda1 ls -l /root/hda1 mount --bind /dev/hda1 /root/hda1 ls -l /root/hda1 But I see tomoyo prevents that MAC can prevent a rogue CAP_SYS_MOUNT process from doing mount --bind /dev/ /root/. For example, regarding TOMOYO Linux, you need to give allow_mount /dev/ /root/ --bind 0 permission to permit mount --bind /dev/ /root/ request. Ok, that answers my question. Thanks. (I won't go into who gets to say allow_mount :) Did you mean ln -s /dev/hda1 /dev/null or ln /dev/hda1 /dev/null? No problem. MAC can prevent such requests too. Then it sounds like this filesystem is something Tomoyo can use. thanks, -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): I hate to bring this again, but what if the admin in the container mounts an external file system (eg. nfs, usb, loop mount from a file, or via fuse), and that file system already has a device that we would like to ban inside that container ? Miklos' user mount patches enforced that if !capable(CAP_MKNOD), then mnt-mnt_flags |= MNT_NODEV. So that's no problem. Yes, that works to disallow all device files from a mounted file system. But it's a black and white thing: either they are all banned or allowed; you can't have some devices allowed and others not, depending on type A scenario where this may be useful is, for instance, if we some apps in the container to execute withing a pre-made chroot (sub)tree within that container. But that's been pulled out of -mm! ? Crap. Since anyway we will have to keep a white- (or black-) list of devices that are permitted in a container, and that list may change even change per container -- why not enforce the access control at the VFS layer ? It's safer in the long run. By that you mean more along the lines of Pavel's patch than my whitelist LSM, or you actually mean Tetsuo's filesystem (i assume you don't mean that by 'vfs layer' :), or something different entirely? :) By 'vfs' I mean at open() time, and not at mount(), or mknod() time. Either yours or Pavel's; I tend to prefer not to use LSM as it may collide with future security modules. Oren. thanks, -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 --bind /dev/hda1 /root/hda1 [EMAIL PROTECTED] ~]# ls -l /root/hda1 brw-r- 1 root disk 3, 1 Dec 18 2007 /root/hda1 Oh, surprising. I didn't know mount() accepts non-directory for mount-point. But I think this is not a mount operation because I can't see the contents of /dev/hda1 through /root/hda1 . Can I see the contents of /dev/hda1 through /root/hda1 ? Then it sounds like this filesystem is something Tomoyo can use. I had / partition mounted for read-only so that the admin can't do 'mknod /root/hda1 b 3 1' in 2003, and I named it Security Advancement Know-how Upon Readonly Approach for Linux or SAKURA Linux. This filesystem (SYAORAN) is developed to make /dev writable and tamper-proof when / partition is read-only or protected by MAC. TOMOYO is a pathname-based MAC implementation, and SAKURA and SYAORAN were merged into TOMOYO Linux. ;-) Regards. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Hello. David Wagner wrote: > If the attacker gets full administrator-level access on your machine, > there are a gazillion ways the attacker can prevent other admins from > logging on. This patch can't prevent that. It sounds like this patch > is trying to solve a fundamentally unsolveable problem. Please be aware that I'm saying "if this filesystem is used with MAC". Without MAC, an attacker who got root privilege can do whatever he/she want to do. But with MAC, an attacker who got root privilege can't do whatever he/she want to do. Only actions permitted by MAC's policy are permitted for the attacker who got root privilege. I'm not saying that "this filesystem can prevent attackers from mounting other filesystem over this filesystem", nor "this filesystem can prevent attackers from executing /sbin/iptables or /usr/bin/passwd". They are MAC's business. What this filesystem can do is "guarantee filename and its attribute". If MAC(such as SELinux, TOMOYO Linux) allows attackers to "mount other filesystem over this filesystem", this filesystem is no longer tamper-proof. But as long as MAC prevents attackers from mounting other filesystem over this filesystem, this filesystem can remain tamper-proof. Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Tetsuo Handa wrote: If Bob is malicious and creates /dev/sda1 with block-8-2 attribute [...] Bob can't do that. Only root can. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Tetsuo Handa writes: >When I attended at Security Stadium 2003 as a defense side, >I was using devfs for /dev directory. The files in /dev directory >were deleted by attckers and the administrator was unable to login. If the attacker gets full administrator-level access on your machine, there are a gazillion ways the attacker can prevent other admins from logging on. This patch can't prevent that. It sounds like this patch is trying to solve a fundamentally unsolveable problem. A useful slogan: "Don't forbid what you cannot prevent." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 plenty of ways to prevent an administrator > from logging in, e.g. using iptables or changing the password. MAC mediates execution of /sbin/iptables or /usr/bin/passwd . So, use of this filesystem alone is meaningless because attackers with root privileges can do what you are saying. But use of this filesystem with MAC is still valid because MAC can prevent attackers with root privileges from doing what you are saying. Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Sun, Dec 16, 2007 at 05:52:08PM +0100, Indan Zupancic wrote: > What prevents them from mounting tmpfs on top of /dev, bypassing your fs? Or binding /dev/null over nodes they want to get rid of... > Also, if they have root there are plenty of ways to prevent an administrator > from logging in, e.g. using iptables or changing the password. Indeed. BTW, tmpfs with root marked append-only and populated in normal ways on boot would get a comparable effect without spending so much efforts. Still won't really help if attacker gains root, but then neither will your variant. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Hi, On Sun, December 16, 2007 13:03, Tetsuo Handa wrote: > Hello. > > David Newall wrote: >> > You won't be able to login to the system because /sbin/mingetty >> > fails to "chown/chmod" /dev/tty* if /dev is mounted for read-only mode. >> >> Good point. So, if only root can modify files in /dev, what's the >> problem you're fixing? (I'm sure you tried to explain this in your >> original post, but your reasons weren't clear to me.) > > In 2003, I was trying to make / partition read-only to avoid tampering system > files. > Use of policy based mandatory access control (such as SELinux) is > one of ways to avoid tampering, but management of policy was a daunting task. > So, I tried to store / partition in a read-only medium so that > the system is free from tampering system files. > > When I attended at Security Stadium 2003 as a defense side, > I was using devfs for /dev directory. The files in /dev directory > were deleted by attckers and the administrator was unable to login. > So I developed this filesystem so that attackers who got root privilege > can't tamper files in /dev directory. What prevents them from mounting tmpfs on top of /dev, bypassing your fs? Also, if they have root there are plenty of ways to prevent an administrator from logging in, e.g. using iptables or changing the password. Greetings, Indan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
> 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 mandatory access control guarantees that "Only Bob can create block device file named sda1 in /dev directory". But it can't guarantee that /dev/sda1 will have block-8-1 attribute. If Bob is malicious and creates /dev/sda1 with block-8-2 attribute, other applications that depends on the attributes of /dev/sda1 goes wrong. So, this filesystem guarantees that /dev/sda1 has block-8-1 attribute. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Hello. David Newall wrote: > > You won't be able to login to the system because /sbin/mingetty > > fails to "chown/chmod" /dev/tty* if /dev is mounted for read-only mode. > > Good point. So, if only root can modify files in /dev, what's the > problem you're fixing? (I'm sure you tried to explain this in your > original post, but your reasons weren't clear to me.) In 2003, I was trying to make / partition read-only to avoid tampering system files. Use of policy based mandatory access control (such as SELinux) is one of ways to avoid tampering, but management of policy was a daunting task. So, I tried to store / partition in a read-only medium so that the system is free from tampering system files. When I attended at Security Stadium 2003 as a defense side, I was using devfs for /dev directory. The files in /dev directory were deleted by attckers and the administrator was unable to login. So I developed this filesystem so that attackers who got root privilege can't tamper files in /dev directory. Not many systems mount / partition for read-only mode, thus there may be few needs for read-only / partition. 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). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Tetsuo Handa wrote: I meant that "/dev must be mounted for read-write mode" Again, why? You won't be able to login to the system because /sbin/mingetty fails to "chown/chmod" /dev/tty* if /dev is mounted for read-only mode. Good point. So, if only root can modify files in /dev, what's the problem you're fixing? (I'm sure you tried to explain this in your original post, but your reasons weren't clear to me.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 /dev is mounted for read-only mode. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Tetsuo Handa wrote: 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 conventional wisdom, which is that /dev must be writable only by the administrator. Why do you say otherwise? I didn't mean that "/dev is writable by everybody". Glad to hear it! :) I meant that "/dev must be mounted for read-write mode" Again, why? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 conventional wisdom, which is that /dev must be writable only by > the administrator. Why do you say otherwise? I didn't mean that "/dev is writable by everybody". I meant that "/dev must be mounted for read-write mode" (even if one wants to mount / for read-only mode). Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 conventional wisdom, which is that /dev must be writable only by the administrator. Why do you say otherwise? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] [RFC] Simple tamper-proof device filesystem.
A brief description about SYAORAN:
SYAORAN stands for "Simple Yet All-important Object Realizing Abiding
Nexus". SYAORAN is a filesystem for /dev with Mandatory Access Control.
/dev needs to be writable, but this means that files on /dev might be
tampered with. SYAORAN can restrict combinations of (pathname, attribute)
that the system can create. The attribute is one of directory, regular
file, FIFO, UNIX domain socket, symbolic link, character or block device
file with major/minor device numbers.
SYAORAN can ensure /dev/null is a character device file with major=1 minor=3.
Policy specifications for this filesystem is at
http://tomoyo.sourceforge.jp/en/1.5.x/policy-syaoran.html
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.
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 +
fs/syaoran/syaoran.h | 964 +++
2 files changed, 1302 insertions(+)
--- /dev/null
+++ linux-2.6.24-rc5/fs/syaoran/syaoran.c
@@ -0,0 +1,338 @@
+/*
+ * fs/syaoran/syaoran.c
+ *
+ * Implementation of the Tamper-Proof Device Filesystem.
+ *
+ * Portions Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 1.5.3-pre 2007/12/16
+ *
+ * This filesystem is developed using the ramfs implementation.
+ *
+ */
+/*
+ * Resizable simple ram filesystem for Linux.
+ *
+ * Copyright (C) 2000 Linus Torvalds.
+ * 2000 Transmeta Corp.
+ *
+ * Usage limits added by David Gibson, Linuxcare Australia.
+ * This file is released under the GPL.
+ */
+
+/*
+ * NOTE! This filesystem is probably most useful
+ * not as a real filesystem, but as an example of
+ * how virtual filesystems can be written.
+ *
+ * It doesn't get much simpler than this. Consider
+ * that this file implements the full semantics of
+ * a POSIX-compliant read-write filesystem.
+ *
+ * Note in particular how the filesystem does not
+ * need to implement any data structures of its own
+ * to keep track of the virtual data: using the VFS
+ * caches is sufficient.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct super_operations syaoran_ops;
+static struct address_space_operations syaoran_aops;
+static struct inode_operations syaoran_file_inode_operations;
+static struct inode_operations syaoran_dir_inode_operations;
+static struct inode_operations syaoran_symlink_inode_operations;
+static struct file_operations syaoran_file_operations;
+
+static struct backing_dev_info syaoran_backing_dev_info = {
+ .ra_pages = 0,/* No readahead */
+ .capabilities = BDI_CAP_NO_ACCT_DIRTY | BDI_CAP_NO_WRITEBACK |
+ BDI_CAP_MAP_DIRECT | BDI_CAP_MAP_COPY |
+ BDI_CAP_READ_MAP | BDI_CAP_WRITE_MAP | BDI_CAP_EXEC_MAP,
+};
+
+#include "syaoran.h"
+
+static struct inode *syaoran_get_inode(struct super_block *sb, int mode,
+ dev_t dev)
+{
+ struct inode *inode = new_inode(sb);
+
+ if (inode) {
+ struct timespec now = CURRENT_TIME;
+ inode->i_mode = mode;
+ inode->i_uid = current->fsuid;
+ inode->i_gid = current->fsgid;
+ inode->i_blocks = 0;
+ inode->i_mapping->a_ops = _aops;
+ inode->i_mapping->backing_dev_info = _backing_dev_info;
+ inode->i_atime = now;
+ inode->i_mtime = now;
+ inode->i_ctime = now;
+ switch (mode & S_IFMT) {
+ default:
+ init_special_inode(inode, mode, dev);
+ if (S_ISBLK(mode))
+ inode->i_fop = _def_blk_fops;
+ else if (S_ISCHR(mode))
+ inode->i_fop = _def_chr_fops;
+ inode->i_op = _file_inode_operations;
+ break;
+ case S_IFREG:
+ inode->i_op = _file_inode_operations;
+ inode->i_fop = _file_operations;
+ break;
+ case S_IFDIR:
+ inode->i_op = _dir_inode_operations;
+ inode->i_fop = _dir_operations;
+ /*
+* directory inodes start off with i_nlink == 2
+* (for "." entry)
+*/
+ inode->i_nlink++;
+ break;
+ case S_IFLNK:
+ inode->i_op = _symlink_inode_operations;
+
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 plenty of ways to prevent an administrator from logging in, e.g. using iptables or changing the password. MAC mediates execution of /sbin/iptables or /usr/bin/passwd . So, use of this filesystem alone is meaningless because attackers with root privileges can do what you are saying. But use of this filesystem with MAC is still valid because MAC can prevent attackers with root privileges from doing what you are saying. Regards. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Tetsuo Handa writes: When I attended at Security Stadium 2003 as a defense side, I was using devfs for /dev directory. The files in /dev directory were deleted by attckers and the administrator was unable to login. If the attacker gets full administrator-level access on your machine, there are a gazillion ways the attacker can prevent other admins from logging on. This patch can't prevent that. It sounds like this patch is trying to solve a fundamentally unsolveable problem. A useful slogan: Don't forbid what you cannot prevent. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Tetsuo Handa wrote: If Bob is malicious and creates /dev/sda1 with block-8-2 attribute [...] Bob can't do that. Only root can. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Hello. David Wagner wrote: If the attacker gets full administrator-level access on your machine, there are a gazillion ways the attacker can prevent other admins from logging on. This patch can't prevent that. It sounds like this patch is trying to solve a fundamentally unsolveable problem. Please be aware that I'm saying if this filesystem is used with MAC. Without MAC, an attacker who got root privilege can do whatever he/she want to do. But with MAC, an attacker who got root privilege can't do whatever he/she want to do. Only actions permitted by MAC's policy are permitted for the attacker who got root privilege. I'm not saying that this filesystem can prevent attackers from mounting other filesystem over this filesystem, nor this filesystem can prevent attackers from executing /sbin/iptables or /usr/bin/passwd. They are MAC's business. What this filesystem can do is guarantee filename and its attribute. If MAC(such as SELinux, TOMOYO Linux) allows attackers to mount other filesystem over this filesystem, this filesystem is no longer tamper-proof. But as long as MAC prevents attackers from mounting other filesystem over this filesystem, this filesystem can remain tamper-proof. Regards. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] [RFC] Simple tamper-proof device filesystem.
A brief description about SYAORAN:
SYAORAN stands for Simple Yet All-important Object Realizing Abiding
Nexus. SYAORAN is a filesystem for /dev with Mandatory Access Control.
/dev needs to be writable, but this means that files on /dev might be
tampered with. SYAORAN can restrict combinations of (pathname, attribute)
that the system can create. The attribute is one of directory, regular
file, FIFO, UNIX domain socket, symbolic link, character or block device
file with major/minor device numbers.
SYAORAN can ensure /dev/null is a character device file with major=1 minor=3.
Policy specifications for this filesystem is at
http://tomoyo.sourceforge.jp/en/1.5.x/policy-syaoran.html
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.
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 +
fs/syaoran/syaoran.h | 964 +++
2 files changed, 1302 insertions(+)
--- /dev/null
+++ linux-2.6.24-rc5/fs/syaoran/syaoran.c
@@ -0,0 +1,338 @@
+/*
+ * fs/syaoran/syaoran.c
+ *
+ * Implementation of the Tamper-Proof Device Filesystem.
+ *
+ * Portions Copyright (C) 2005-2007 NTT DATA CORPORATION
+ *
+ * Version: 1.5.3-pre 2007/12/16
+ *
+ * This filesystem is developed using the ramfs implementation.
+ *
+ */
+/*
+ * Resizable simple ram filesystem for Linux.
+ *
+ * Copyright (C) 2000 Linus Torvalds.
+ * 2000 Transmeta Corp.
+ *
+ * Usage limits added by David Gibson, Linuxcare Australia.
+ * This file is released under the GPL.
+ */
+
+/*
+ * NOTE! This filesystem is probably most useful
+ * not as a real filesystem, but as an example of
+ * how virtual filesystems can be written.
+ *
+ * It doesn't get much simpler than this. Consider
+ * that this file implements the full semantics of
+ * a POSIX-compliant read-write filesystem.
+ *
+ * Note in particular how the filesystem does not
+ * need to implement any data structures of its own
+ * to keep track of the virtual data: using the VFS
+ * caches is sufficient.
+ */
+
+#include linux/module.h
+#include linux/fs.h
+#include linux/pagemap.h
+#include linux/highmem.h
+#include linux/time.h
+#include linux/init.h
+#include linux/string.h
+#include linux/backing-dev.h
+#include linux/sched.h
+#include linux/uaccess.h
+
+static struct super_operations syaoran_ops;
+static struct address_space_operations syaoran_aops;
+static struct inode_operations syaoran_file_inode_operations;
+static struct inode_operations syaoran_dir_inode_operations;
+static struct inode_operations syaoran_symlink_inode_operations;
+static struct file_operations syaoran_file_operations;
+
+static struct backing_dev_info syaoran_backing_dev_info = {
+ .ra_pages = 0,/* No readahead */
+ .capabilities = BDI_CAP_NO_ACCT_DIRTY | BDI_CAP_NO_WRITEBACK |
+ BDI_CAP_MAP_DIRECT | BDI_CAP_MAP_COPY |
+ BDI_CAP_READ_MAP | BDI_CAP_WRITE_MAP | BDI_CAP_EXEC_MAP,
+};
+
+#include syaoran.h
+
+static struct inode *syaoran_get_inode(struct super_block *sb, int mode,
+ dev_t dev)
+{
+ struct inode *inode = new_inode(sb);
+
+ if (inode) {
+ struct timespec now = CURRENT_TIME;
+ inode-i_mode = mode;
+ inode-i_uid = current-fsuid;
+ inode-i_gid = current-fsgid;
+ inode-i_blocks = 0;
+ inode-i_mapping-a_ops = syaoran_aops;
+ inode-i_mapping-backing_dev_info = syaoran_backing_dev_info;
+ inode-i_atime = now;
+ inode-i_mtime = now;
+ inode-i_ctime = now;
+ switch (mode S_IFMT) {
+ default:
+ init_special_inode(inode, mode, dev);
+ if (S_ISBLK(mode))
+ inode-i_fop = wrapped_def_blk_fops;
+ else if (S_ISCHR(mode))
+ inode-i_fop = wrapped_def_chr_fops;
+ inode-i_op = syaoran_file_inode_operations;
+ break;
+ case S_IFREG:
+ inode-i_op = syaoran_file_inode_operations;
+ inode-i_fop = syaoran_file_operations;
+ break;
+ case S_IFDIR:
+ inode-i_op = syaoran_dir_inode_operations;
+ inode-i_fop = simple_dir_operations;
+ /*
+* directory inodes start off with i_nlink == 2
+* (for . entry)
+*/
+
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 conventional wisdom, which is that /dev must be writable only by the administrator. Why do you say otherwise? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 conventional wisdom, which is that /dev must be writable only by the administrator. Why do you say otherwise? I didn't mean that /dev is writable by everybody. I meant that /dev must be mounted for read-write mode (even if one wants to mount / for read-only mode). Regards. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Tetsuo Handa wrote: 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 conventional wisdom, which is that /dev must be writable only by the administrator. Why do you say otherwise? I didn't mean that /dev is writable by everybody. Glad to hear it! :) I meant that /dev must be mounted for read-write mode Again, why? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 /dev is mounted for read-only mode. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Tetsuo Handa wrote: I meant that /dev must be mounted for read-write mode Again, why? You won't be able to login to the system because /sbin/mingetty fails to chown/chmod /dev/tty* if /dev is mounted for read-only mode. Good point. So, if only root can modify files in /dev, what's the problem you're fixing? (I'm sure you tried to explain this in your original post, but your reasons weren't clear to me.) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Hello. David Newall wrote: You won't be able to login to the system because /sbin/mingetty fails to chown/chmod /dev/tty* if /dev is mounted for read-only mode. Good point. So, if only root can modify files in /dev, what's the problem you're fixing? (I'm sure you tried to explain this in your original post, but your reasons weren't clear to me.) In 2003, I was trying to make / partition read-only to avoid tampering system files. Use of policy based mandatory access control (such as SELinux) is one of ways to avoid tampering, but management of policy was a daunting task. So, I tried to store / partition in a read-only medium so that the system is free from tampering system files. When I attended at Security Stadium 2003 as a defense side, I was using devfs for /dev directory. The files in /dev directory were deleted by attckers and the administrator was unable to login. So I developed this filesystem so that attackers who got root privilege can't tamper files in /dev directory. Not many systems mount / partition for read-only mode, thus there may be few needs for read-only / partition. 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). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
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 mandatory access control guarantees that Only Bob can create block device file named sda1 in /dev directory. But it can't guarantee that /dev/sda1 will have block-8-1 attribute. If Bob is malicious and creates /dev/sda1 with block-8-2 attribute, other applications that depends on the attributes of /dev/sda1 goes wrong. So, this filesystem guarantees that /dev/sda1 has block-8-1 attribute. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
Hi, On Sun, December 16, 2007 13:03, Tetsuo Handa wrote: Hello. David Newall wrote: You won't be able to login to the system because /sbin/mingetty fails to chown/chmod /dev/tty* if /dev is mounted for read-only mode. Good point. So, if only root can modify files in /dev, what's the problem you're fixing? (I'm sure you tried to explain this in your original post, but your reasons weren't clear to me.) In 2003, I was trying to make / partition read-only to avoid tampering system files. Use of policy based mandatory access control (such as SELinux) is one of ways to avoid tampering, but management of policy was a daunting task. So, I tried to store / partition in a read-only medium so that the system is free from tampering system files. When I attended at Security Stadium 2003 as a defense side, I was using devfs for /dev directory. The files in /dev directory were deleted by attckers and the administrator was unable to login. So I developed this filesystem so that attackers who got root privilege can't tamper files in /dev directory. What prevents them from mounting tmpfs on top of /dev, bypassing your fs? Also, if they have root there are plenty of ways to prevent an administrator from logging in, e.g. using iptables or changing the password. Greetings, Indan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Sun, Dec 16, 2007 at 05:52:08PM +0100, Indan Zupancic wrote: What prevents them from mounting tmpfs on top of /dev, bypassing your fs? Or binding /dev/null over nodes they want to get rid of... Also, if they have root there are plenty of ways to prevent an administrator from logging in, e.g. using iptables or changing the password. Indeed. BTW, tmpfs with root marked append-only and populated in normal ways on boot would get a comparable effect without spending so much efforts. Still won't really help if attacker gains root, but then neither will your variant. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
