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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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,
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
--- [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
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
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
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
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
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
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
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
--- [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
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] ~]#
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
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
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
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 ?
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
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
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
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
( 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
>
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
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
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
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.
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
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
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
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
Hello.
Al Boldi wrote:
I think the answer is obvious: Tetsuo wants to add functionality that the
MACs are missing. So, instead of adding this functionality per MAC, he
proposes to add it as ground work, to be combined with any MAC.
Yes, that's right.
This filesystem is designed to be used
( This is a reply to http://lkml.org/lkml/2007/12/17/27 .)
Hello.
David Wagner wrote:
But the point is that it's not enough just to prevent attackers
from mounting other filesystems over this filesystem. I can think
of all sorts of ways that an admin-level attacker might be able to
prevent
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
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]):
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
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
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;
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'
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
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
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
Hello.
Serge E. Hallyn wrote:
Nope, try
touch /root/hda1
ls -l /root/hda1
mount --bind /dev/hda1 /root/hda1
ls -l /root/hda1
[EMAIL PROTECTED] ~]# touch /root/hda1
[EMAIL PROTECTED] ~]# ls -l /root/hda1
-rw-r--r-- 1 root root 0 Dec 18 12:04 /root/hda1
[EMAIL PROTECTED] ~]# mount
Hello.
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
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
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
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
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
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
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
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"
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.)
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
>
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
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
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
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
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
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.
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
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
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
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.)
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
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,
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
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
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
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,
92 matches
Mail list logo
