On Fri, Jan 11, 2008 at 11:05:07PM +0900, Tetsuo Handa wrote:
> Not only mknod() but also rename()/unlink()/link()/mount(bind) etc. that may
> cause filename/attribute mismatching.
>
> How can the daemon know whether the request is trying to manipulate nodes
> in /dev directory or not?
> If "mount
Hello.
Indan Zupancic wrote:
> That "only the tiny daemon can modify /dev/" is done with MAC rules,
> the ones that should be the default for all applications except udev by
> default already. For teh kernel nothing changes.
OK. You assume use of MAC with enough fine grained access control.
Hi,
On Fri, January 11, 2008 09:46, Tetsuo Handa wrote:
> It depends.
> Some users have to continue using brain dead legacy applications
> without modification because ...
>
>the application's source code is not available.
Source isn't needed, as long as the vendor has it.
>the distribut
Hello.
Indan Zupancic wrote:
> > It seems to me that the alternatives you are proposing include
> > modification of userland applications. But my assumption is
> > that "Don't require modification of userland applications".
>
> If you want a secure system it isn't that unreasonable to expect
>
On Thu, January 10, 2008 05:57, Tetsuo Handa wrote:
> It seems to me that the alternatives you are proposing include
> modification of userland applications. But my assumption is
> that "Don't require modification of userland applications".
If you want a secure system it isn't that unreasonable to
Hello.
Indan Zupancic wrote:
> Good point, but I assume they all have at least a directory granularity, and
> then
> /dev/ can be static and udev and other can have free reign in e.g.
> /dev/dynamic/.
> Just use subdirs for the dynamic stuff and this granularity problem is, with
> slight inconve
On Thu, January 10, 2008 00:08, Serge E. Hallyn wrote:
> These emails again are getting really long, but I think the gist of
> Indan's suggestion can be concisely summarized:
No worry, I wasn't planning on extending it, I've said what I've to say.
Except...
>
> "To confine process P3 to /d
Quoting Indan Zupancic ([EMAIL PROTECTED]):
> Hello,
>
> On Wed, January 9, 2008 05:39, Tetsuo Handa wrote:
> > Hello.
> >
> > Indan Zupancic wrote:
> >> I think you focus too much on your way of enforcing filename/attributes
> >> pairs.
> > So?
>
> So that you miss alternatives and don't see the
Hello,
On Wed, January 9, 2008 05:39, Tetsuo Handa wrote:
> Hello.
>
> Indan Zupancic wrote:
>> I think you focus too much on your way of enforcing filename/attributes
>> pairs.
> So?
So that you miss alternatives and don't see the bigger picture.
>
>> The same can be achieved by creating the de
Hello.
[EMAIL PROTECTED] wrote:
> Good summary - probably should add that to the patch, drop it into
> Documentation/syaoran-config.txt or similar...
I see.
> Modification while reading *is* an issue, but can probably be worked around
> with some clever locking. The race condition I was thinking
On Tue, 08 Jan 2008 22:50:43 +0900, Tetsuo Handa said:
> Yes. It is a line-by-line processable format defined as:
>
> filename permission owner group flags type [ symlink_data | major minor ]
>
> where flags are bit-wised combinations of
>
> * 1: Allow creation of the file.
> * 2: Allow
Hello.
Indan Zupancic wrote:
> I think you focus too much on your way of enforcing filename/attributes
> pairs.
So?
> The same can be achieved by creating the device nodes with
> expected attributes, and preventing processes from changing those files.
The device nodes have to be deletable if some
Hi Tetsuo,
I think you focus too much on your way of enforcing filename/attributes
pairs. The same can be achieved by creating the device nodes with
expected attributes, and preventing processes from changing those files.
This because expected combinations are known beforehand. And once
those file
Hello.
Indan Zupancic wrote:
> > I want to use this filesystem in case where a process with root privilege
> > was
> > hijacked but the behavior of the hijacked process is still restricted by
> > MAC.
>
> 1) If the behaviour can be controlled, why can't the process be
>disallowed to change
Hello.
[EMAIL PROTECTED] wrote:
> Ouch. The .c files should generally be built into their own .o files and
> then the Makefile should do something like
>
> obj-$(CONFIG_SYAORAN) += syaoran.o
>
> unless there's *really* good reasons for including .c files (such as an
> otherwise-messy variable-n
Hello,
Some questions:
On Sun, January 6, 2008 16:20, Tetsuo Handa wrote:
> I want to use this filesystem in case where a process with root privilege was
> hijacked but the behavior of the hijacked process is still restricted by MAC.
1) If the behaviour can be controlled, why can't the process b
On Sun, 06 Jan 2008 15:20:00 +0900, Tetsuo Handa said:
> --- linux-2.6-mm.orig/fs/ramfs/inode.c
> +++ linux-2.6-mm/fs/ramfs/inode.c
> @@ -36,6 +36,20 @@
> #include
> #include "internal.h"
>
> +static struct inode *__ramfs_get_inode(struct super_block *sb, int mode,
> +
Hello.
Changes from previous posting:
(1) I rebased this patch using tmpfs.
I didn't know I was making this patch using ramfs...
This patch is for 2.6.24-rc6-mm1.
Regards.
--
Subject: Simple tamper-proof device filesystem.
The goal of this filesystem is to guarantee that
"applic
On Sun, Jan 06, 2008 at 04:36:06PM +0900, Tetsuo Handa wrote:
> Hello.
>
> Willy Tarreau wrote:
> > Your patch is very confusing. In your description, as well as in the
> > comments you talk about tmpfs, but your patch does not touch even one
> > line of tmpfs and only changes ramfs. Even your var
Hello.
Willy Tarreau wrote:
> Your patch is very confusing. In your description, as well as in the
> comments you talk about tmpfs, but your patch does not touch even one
> line of tmpfs and only changes ramfs. Even your variables and arguments
> refer to tmpfs. The Kconfig entry indicates that th
Hello,
On Sun, Jan 06, 2008 at 03:20:00PM +0900, Tetsuo Handa wrote:
> Hello.
>
> Changes from previous posting:
>
> (1) Added kernel config so that users can choose
> whether to compile this filesystem or not.
>
> I didn't receive any ACK/NACK regarding whether I'm permitted to
>
Hello.
Changes from previous posting:
(1) Added kernel config so that users can choose
whether to compile this filesystem or not.
I didn't receive any ACK/NACK regarding whether I'm permitted to
implement this filesystem as an extension to tmpfs or not.
So, I continued imple
Hello.
Thank you for reviewing.
Serge E. Hallyn wrote:
> > This time, I'm implementing this filesystem as an extension to tmpfs
> > because what this filesystem does are nothing but check filename and
> > its attributes in addition to what tmpfs does.
>
> To integrate this nicer into tmpfs, at l
Quoting Tetsuo Handa ([EMAIL PROTECTED]):
> Hello.
>
> Thank you for attending discussion for previous posting
> (starting from http://lkml.org/lkml/2007/12/16/23 ).
>
> The previous posting was for feasibility test to know
> whether this kind of trivial filesystem is acceptable for mainline.
>
Hello.
Thank you for attending discussion for previous posting
(starting from http://lkml.org/lkml/2007/12/16/23 ).
The previous posting was for feasibility test to know
whether this kind of trivial filesystem is acceptable for mainline.
Now, it seems that there is a little chance for accepting.
25 matches
Mail list logo
