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 o
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
>>
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 i
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 s
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 mo
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 chan
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_M
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 syste
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 vi
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
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 w
--- [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 g
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
> >
> 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 a
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
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
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] ~]# mo
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 i
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 stil
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_
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 ?
Mik
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/sd
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-)
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'
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)
>
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 mi
( 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
> preve
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
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 r
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
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 reque
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.
Tets
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 proble
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
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
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 pl
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,
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,
> 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 base
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 expla
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 /de
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*
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.) Thi
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
> agai
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
45 matches
Mail list logo
