Write-once file system

Write-once file system

[Fong Vang]

We rely heavily on reiserfs for some of our critical file systems.  I'm just
wondering what work would be involved and how difficult it would be to add
an option (perhaps at mount time) to reiserfs that will allow a file to be
written only once, i.e. once a file is created it should not be allowed to
be modified or deleted (including the inode).  We may consider paying for
this modification.



This e-mail has been captured and archived by the ZANTAZ Digital Safe(tm)
service.  For more information, visit us at www.zantaz.com. 
IMPORTANT: This electronic mail message is intended only for the use of the
individual or entity to which it is addressed and may contain information
that is privileged, confidential or exempt from disclosure under applicable
law.  If the reader of this message is not the intended recipient, or the
employee or agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If you have received
this communication in error, please notify the sender immediately by
telephone or directly reply to the original message(s) sent.  Thank you.

Re: Write-once file system

[Oleg Drokin]

Hello!

On Fri, Jun 27, 2003 at 08:43:06AM -0700, Fong Vang wrote:
> We rely heavily on reiserfs for some of our critical file systems.  I'm just
> wondering what work would be involved and how difficult it would be to add
> an option (perhaps at mount time) to reiserfs that will allow a file to be
> written only once, i.e. once a file is created it should not be allowed to
> be modified or deleted (including the inode).  We may consider paying for
> this modification.

Is the extended attributes support (man chattr) does what you want by any chance?

Bye,
    Oleg

Re: Write-once file system

[Hans Reiser]

Fong Vang wrote:

>We rely heavily on reiserfs for some of our critical file systems.  I'm just
>wondering what work would be involved and how difficult it would be to add
>an option (perhaps at mount time) to reiserfs that will allow a file to be
>written only once, i.e. once a file is created it should not be allowed to
>be modified or deleted (including the inode).  We may consider paying for
>this modification.
>
>
>
>This e-mail has been captured and archived by the ZANTAZ Digital Safe(tm)
>service.  For more information, visit us at www.zantaz.com. 
>IMPORTANT: This electronic mail message is intended only for the use of the
>individual or entity to which it is addressed and may contain information
>that is privileged, confidential or exempt from disclosure under applicable
>law.  If the reader of this message is not the intended recipient, or the
>employee or agent responsible for delivering this message to the intended
>recipient, you are hereby notified that any dissemination, distribution or
>copying of this communication is strictly prohibited.  If you have received
>this communication in error, please notify the sender immediately by
>telephone or directly reply to the original message(s) sent.  Thank you.
>
>
>  
>
Do you intend to first write it, and then indicate that it should no 
longer be modifiable?  Or do you want it to be unmodifiable as it is 
being appended to?  Do you want it to be safe from root?  Do you want it 
to be safe from rebooting to a new kernel?

-- 
Hans

RE: Write-once file system

[Fong Vang]

Once the write to the file is CLOSED the file should not be modifiable in
any way.  It should not be writeable by root.  Ideally, this should be
across reboot and across kernel.  The current requirement is that as long as
the modified kernel/reisefs is being used then it should NOT be modifiable
(if a kernel allowing modification is used then it could allow
modifications).

-----Original Message-----
From: Hans Reiser [mailto:reiser@namesys.com]
Sent: Friday, June 27, 2003 8:49 AM
To: Fong Vang
Cc: 'reiserfs-list@namesys.com'
Subject: Re: Write-once file system


Fong Vang wrote:

>We rely heavily on reiserfs for some of our critical file systems.  I'm
just
>wondering what work would be involved and how difficult it would be to add
>an option (perhaps at mount time) to reiserfs that will allow a file to be
>written only once, i.e. once a file is created it should not be allowed to
>be modified or deleted (including the inode).  We may consider paying for
>this modification.
>
>
>
>This e-mail has been captured and archived by the ZANTAZ Digital Safe(tm)
>service.  For more information, visit us at www.zantaz.com. 
>IMPORTANT: This electronic mail message is intended only for the use of the
>individual or entity to which it is addressed and may contain information
>that is privileged, confidential or exempt from disclosure under applicable
>law.  If the reader of this message is not the intended recipient, or the
>employee or agent responsible for delivering this message to the intended
>recipient, you are hereby notified that any dissemination, distribution or
>copying of this communication is strictly prohibited.  If you have received
>this communication in error, please notify the sender immediately by
>telephone or directly reply to the original message(s) sent.  Thank you.
>
>
>  
>
Do you intend to first write it, and then indicate that it should no 
longer be modifiable?  Or do you want it to be unmodifiable as it is 
being appended to?  Do you want it to be safe from root?  Do you want it 
to be safe from rebooting to a new kernel?

-- 
Hans



This e-mail has been captured and archived by the ZANTAZ Digital Safe(tm)
service.  For more information, visit us at www.zantaz.com. 
IMPORTANT: This electronic mail message is intended only for the use of the
individual or entity to which it is addressed and may contain information
that is privileged, confidential or exempt from disclosure under applicable
law.  If the reader of this message is not the intended recipient, or the
employee or agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If you have received
this communication in error, please notify the sender immediately by
telephone or directly reply to the original message(s) sent.  Thank you.

Re: Write-once file system

[Oleg Drokin]

Hello!

On Fri, Jun 27, 2003 at 09:07:05AM -0700, Fong Vang wrote:
> Once the write to the file is CLOSED the file should not be modifiable in
> any way.  It should not be writeable by root.  Ideally, this should be
> across reboot and across kernel.  The current requirement is that as long as
> the modified kernel/reisefs is being used then it should NOT be modifiable
> (if a kernel allowing modification is used then it could allow
> modifications).

So basically do you think it would be better for you to have "write-once flag" in superblock
that will make all files to be unwritable (except newly created ones) as opposed to a simple
mount option that you'd use for filesystems with non-changeable files?
(you need to mark filesystems that are in write-once mode somehow, because I think
you do not need all reiserfs filesystems to be run in this mode, right?)
Also concerning the "root should not be able to change the files", root
will be able to overwrite files by using block devices if he'd want to.

Bye,
    Oleg

Re: Write-once file system

[Andreas Dilger]

On Jun 27, 2003  09:07 -0700, Fong Vang wrote:
> Once the write to the file is CLOSED the file should not be modifiable in
> any way.  It should not be writeable by root.  Ideally, this should be
> across reboot and across kernel.  The current requirement is that as long as
> the modified kernel/reisefs is being used then it should NOT be modifiable
> (if a kernel allowing modification is used then it could allow
> modifications).

Sounds like "immutable" (chattr +i) support is what you want.  It looks
like reiserfs already supports this.  Even root can not overwrite or delete
an immutable file, but could disable the immutable flag first (chattr -i)
before doing so.  Regular users can never disable the immutable flag once
set without the CAP_LINUX_IMMUTABLE capability.  However, it looks like
the reiserfs code has a bug there - any user can clear the immutable flag
(see ext[23]_ioctl() for proper permission check).

In BSD (AFAIK), removing the immutable flag requires that you be booted
into runlevel 1 (single user) but in Linux it can currently be done at any
time, although I imagine it would be pretty easy to fix that.

You should be able to set the immutable flag on a directory and have it
inherited by all files created in that directory.

> Fong Vang wrote:
> >We rely heavily on reiserfs for some of our critical file systems.  I'm
> >wondering what work would be involved and how difficult it would be to add
> >an option (perhaps at mount time) to reiserfs that will allow a file to be
> >written only once, i.e. once a file is created it should not be allowed to
> >be modified or deleted (including the inode).  We may consider paying for
> >this modification.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

RE: Write-once file system

[Fong Vang]

it should be mandantory.  root should not be able to change it.

-----Original Message-----
From: Oleg Drokin [mailto:green@namesys.com]
Sent: Friday, June 27, 2003 8:46 AM
To: Fong Vang
Cc: 'reiserfs-list@namesys.com'
Subject: Re: Write-once file system


Hello!

On Fri, Jun 27, 2003 at 08:43:06AM -0700, Fong Vang wrote:
> We rely heavily on reiserfs for some of our critical file systems.  I'm
just
> wondering what work would be involved and how difficult it would be to add
> an option (perhaps at mount time) to reiserfs that will allow a file to be
> written only once, i.e. once a file is created it should not be allowed to
> be modified or deleted (including the inode).  We may consider paying for
> this modification.

Is the extended attributes support (man chattr) does what you want by any
chance?

Bye,
    Oleg


This e-mail has been captured and archived by the ZANTAZ Digital Safe(tm)
service.  For more information, visit us at www.zantaz.com. 
IMPORTANT: This electronic mail message is intended only for the use of the
individual or entity to which it is addressed and may contain information
that is privileged, confidential or exempt from disclosure under applicable
law.  If the reader of this message is not the intended recipient, or the
employee or agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If you have received
this communication in error, please notify the sender immediately by
telephone or directly reply to the original message(s) sent.  Thank you.

RE: Write-once file system

[Fong Vang]

I don't think turning the write option off during write is a good idea.  All
file systems running reiserfs should make the file write-once.  File systems
that do need to be rewriteable will use ext3 or something else (that's how
we do it now anyway).

Could it done in such a way that even root can't write (not even when using
block devices)?

-----Original Message-----
From: Oleg Drokin [mailto:green@namesys.com]
Sent: Friday, June 27, 2003 9:20 AM
To: Fong Vang
Cc: 'Hans Reiser'; 'reiserfs-list@namesys.com'
Subject: Re: Write-once file system


Hello!

On Fri, Jun 27, 2003 at 09:07:05AM -0700, Fong Vang wrote:
> Once the write to the file is CLOSED the file should not be modifiable in
> any way.  It should not be writeable by root.  Ideally, this should be
> across reboot and across kernel.  The current requirement is that as long
as
> the modified kernel/reisefs is being used then it should NOT be modifiable
> (if a kernel allowing modification is used then it could allow
> modifications).

So basically do you think it would be better for you to have "write-once
flag" in superblock
that will make all files to be unwritable (except newly created ones) as
opposed to a simple
mount option that you'd use for filesystems with non-changeable files?
(you need to mark filesystems that are in write-once mode somehow, because I
think
you do not need all reiserfs filesystems to be run in this mode, right?)
Also concerning the "root should not be able to change the files", root
will be able to overwrite files by using block devices if he'd want to.

Bye,
    Oleg


This e-mail has been captured and archived by the ZANTAZ Digital Safe(tm)
service.  For more information, visit us at www.zantaz.com. 
IMPORTANT: This electronic mail message is intended only for the use of the
individual or entity to which it is addressed and may contain information
that is privileged, confidential or exempt from disclosure under applicable
law.  If the reader of this message is not the intended recipient, or the
employee or agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If you have received
this communication in error, please notify the sender immediately by
telephone or directly reply to the original message(s) sent.  Thank you.

RE: Write-once file system

[Jason Holt]

On Fri, 27 Jun 2003, Fong Vang wrote:

> I don't think turning the write option off during write is a good idea.  All
> file systems running reiserfs should make the file write-once.  File systems
> that do need to be rewriteable will use ext3 or something else (that's how
> we do it now anyway).
> 
> Could it done in such a way that even root can't write (not even when using
> block devices)?
[...]

The trick is that root controls the kernel, and the kernel talks directly to
the hardware.  That's all a block device is - (mostly) direct hardware access.

So what you're asking for is something beyond root's control that can tell him
"no" when he asks to write to an immutable file.

Hardware would be one such option - a disk which knows what has been written
and will refuse to write over it.

A separate machine would be another, serving up a write-once filesystem over a
network.

It might even be possible to have two virtual machines on the same box.  
User-mode linux, for instance, lets you create a virtual linux box on a
machine - you have root on the virtual machine, but not necessarily on the
real one.  Obviously, somebody else will have to be the "real" root, and
they'd be able to access the real block devices.  And of course, anybody that
has physical access to a box can almost certainly gain root on it.

					-J

Re: Write-once file system

[Russell Coker]

On Sat, 28 Jun 2003 03:09, Jason Holt wrote:
> On Fri, 27 Jun 2003, Fong Vang wrote:
> > I don't think turning the write option off during write is a good idea. 
> > All file systems running reiserfs should make the file write-once.  File
> > systems that do need to be rewriteable will use ext3 or something else
> > (that's how we do it now anyway).
> >
> > Could it done in such a way that even root can't write (not even when
> > using block devices)?
>
> [...]
>
> The trick is that root controls the kernel, and the kernel talks directly
> to the hardware.  That's all a block device is - (mostly) direct hardware
> access.
>
> So what you're asking for is something beyond root's control that can tell
> him "no" when he asks to write to an immutable file.

Another option is to use a security system such as SE Linux to limit the 
access given to the root account.

In SE Linux a daemon running as root generally has very little access to the 
system, and a UID=0 user who is in the user_t domain gets less access than a 
non-root user on a non-SE system.

Go to my SE Linux web page (below) and read about my "play machine".

SE Linux works well on ReiserFS.  I don't use ReiserFS on my play machine 
however because it can only boot from Ext2, Ext3, or XFS.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

RE: Write-once file system

[bscott]

On Fri, 27 Jun 2003, at 5:09pm, jason@lunkwill.org wrote:
> So what you're asking for is something beyond root's control that can tell
> him "no" when he asks to write to an immutable file.

  That is acknowledged.  However, the EXT2/3 filesystem drivers still
prevent *any* process from writing to an immutable file, privileged or
otherwise.  Of course, root can simply remove the immutable bit, but the
idea is that it has to be a *deliberate* action.

  Protecting against mistakes done by an operator running as "root" is also
valid, even if one cannot protect against an attacker running as "root".

  Thus, I submit that a "write once" or "append only" mechanism should be
honored by the filesystem driver, even if the process has root privileges.

-- 
Ben Scott <bscott@ntisys.com>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.              |

RE: Write-once file system

[Fong Vang]

this doesn't seem to work on kernel 2.4.20.  I did a chattr +i on file but
rm -rf (as root) on the file deletes it.


-----Original Message-----
From: Andreas Dilger [mailto:adilger@clusterfs.com]
Sent: Friday, June 27, 2003 10:01 AM
To: Fong Vang
Cc: 'Hans Reiser'; 'reiserfs-list@namesys.com'
Subject: Re: Write-once file system


On Jun 27, 2003  09:07 -0700, Fong Vang wrote:
> Once the write to the file is CLOSED the file should not be modifiable in
> any way.  It should not be writeable by root.  Ideally, this should be
> across reboot and across kernel.  The current requirement is that as long
as
> the modified kernel/reisefs is being used then it should NOT be modifiable
> (if a kernel allowing modification is used then it could allow
> modifications).

Sounds like "immutable" (chattr +i) support is what you want.  It looks
like reiserfs already supports this.  Even root can not overwrite or delete
an immutable file, but could disable the immutable flag first (chattr -i)
before doing so.  Regular users can never disable the immutable flag once
set without the CAP_LINUX_IMMUTABLE capability.  However, it looks like
the reiserfs code has a bug there - any user can clear the immutable flag
(see ext[23]_ioctl() for proper permission check).

In BSD (AFAIK), removing the immutable flag requires that you be booted
into runlevel 1 (single user) but in Linux it can currently be done at any
time, although I imagine it would be pretty easy to fix that.

You should be able to set the immutable flag on a directory and have it
inherited by all files created in that directory.

> Fong Vang wrote:
> >We rely heavily on reiserfs for some of our critical file systems.  I'm
> >wondering what work would be involved and how difficult it would be to
add
> >an option (perhaps at mount time) to reiserfs that will allow a file to
be
> >written only once, i.e. once a file is created it should not be allowed
to
> >be modified or deleted (including the inode).  We may consider paying for
> >this modification.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/


This e-mail has been captured and archived by the ZANTAZ Digital Safe(tm)
service.  For more information, visit us at www.zantaz.com. 
IMPORTANT: This electronic mail message is intended only for the use of the
individual or entity to which it is addressed and may contain information
that is privileged, confidential or exempt from disclosure under applicable
law.  If the reader of this message is not the intended recipient, or the
employee or agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If you have received
this communication in error, please notify the sender immediately by
telephone or directly reply to the original message(s) sent.  Thank you.

Re: Write-once file system

['Andreas Dilger']

On Jun 27, 2003  10:07 -0700, Fong Vang wrote:
> this doesn't seem to work on kernel 2.4.20.  I did a chattr +i on file but
> rm -rf (as root) on the file deletes it.

That is a reiserfs bug then...  I just tested it with ext3 and it worked as
expected.

[root]# chattr +i /tmp/ttt
[root]# echo foo >> /tmp/ttt
bash: /tmp/ttt: Permission denied
[root]# cp /etc/hosts /tmp/ttt
cp: cannot create regular file `/tmp/ttt': Permission denied
[root]# mv /tmp/cvsErIatf /tmp/ttt
mv: cannot move `/tmp/cvsErIatf' to `/tmp/ttt': Operation not permitted
[root]# rm -f /tmp/ttt
rm: cannot unlink `/tmp/ttt': Operation not permitted
[root]# mv /tmp/ttt /tmp/foo
mv: cannot unlink `/tmp/ttt': Operation not permitted
mv: cannot remove `/tmp/ttt': Operation not permitted


Note however, that I now see that an immutable directory can not have new
files created in it, so there is no easy way for new files to inherit the
immutable flag.  That could probably be done on a per-filesystem basis by
mounting with a new option "inherit=immutable" or something like that.

Andreas Dilger [mailto:adilger@clusterfs.com] wrote:
> On Jun 27, 2003  09:07 -0700, Fong Vang wrote:
> > Once the write to the file is CLOSED the file should not be modifiable in
> > any way.  It should not be writeable by root.  Ideally, this should be
> > across reboot and across kernel.  The current requirement is that as long
> as
> > the modified kernel/reisefs is being used then it should NOT be modifiable
> > (if a kernel allowing modification is used then it could allow
> > modifications).
> 
> Sounds like "immutable" (chattr +i) support is what you want.  It looks
> like reiserfs already supports this.  Even root can not overwrite or delete
> an immutable file, but could disable the immutable flag first (chattr -i)
> before doing so.  Regular users can never disable the immutable flag once
> set without the CAP_LINUX_IMMUTABLE capability.  However, it looks like
> the reiserfs code has a bug there - any user can clear the immutable flag
> (see ext[23]_ioctl() for proper permission check).
> 
> In BSD (AFAIK), removing the immutable flag requires that you be booted
> into runlevel 1 (single user) but in Linux it can currently be done at any
> time, although I imagine it would be pretty easy to fix that.
> 
> You should be able to set the immutable flag on a directory and have it
> inherited by all files created in that directory.
> 
> > Fong Vang wrote:
> > >We rely heavily on reiserfs for some of our critical file systems.  I'm
> > >wondering what work would be involved and how difficult it would be to
> add
> > >an option (perhaps at mount time) to reiserfs that will allow a file to
> be
> > >written only once, i.e. once a file is created it should not be allowed
> to
> > >be modified or deleted (including the inode).  We may consider paying for
> > >this modification.
> 
> Cheers, Andreas
> --
> Andreas Dilger
> http://sourceforge.net/projects/ext2resize/
> http://www-mddsp.enel.ucalgary.ca/People/adilger/

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: Write-once file system

[Oleg Drokin]

Hello!

On Fri, Jun 27, 2003 at 11:27:22AM -0600, 'Andreas Dilger' wrote:

> > this doesn't seem to work on kernel 2.4.20.  I did a chattr +i on file but
> > rm -rf (as root) on the file deletes it.
> That is a reiserfs bug then...  I just tested it with ext3 and it worked as
> expected.

No, it is documented reiserfs feature. You must enable extended attributes 
support at mount time.

Bye,
    Oleg

Re: Write-once file system

[Oleg Drokin]

Hello!

On Fri, Jun 27, 2003 at 10:07:05AM -0700, Fong Vang wrote:
> this doesn't seem to work on kernel 2.4.20.  I did a chattr +i on file but
> rm -rf (as root) on the file deletes it.

You need to mount with -o attrs mount option for extended attributes to work.

Bye,
    Oleg

RE: Write-once file system

[Fong Vang]

Physical access to the machine is a separate issue which we're already
addressing with biometrics and other measures.

Could root be disabled completely?  I haven't tried this before so I don't
know what impact disabling root on the system would do.

-----Original Message-----
From: Jason Holt [mailto:jason@lunkwill.org]
Sent: Friday, June 27, 2003 10:09 AM
To: Fong Vang
Cc: 'Oleg Drokin'; 'Hans Reiser'; 'reiserfs-list@namesys.com'
Subject: RE: Write-once file system



On Fri, 27 Jun 2003, Fong Vang wrote:

> I don't think turning the write option off during write is a good idea.
All
> file systems running reiserfs should make the file write-once.  File
systems
> that do need to be rewriteable will use ext3 or something else (that's how
> we do it now anyway).
> 
> Could it done in such a way that even root can't write (not even when
using
> block devices)?
[...]

The trick is that root controls the kernel, and the kernel talks directly to
the hardware.  That's all a block device is - (mostly) direct hardware
access.

So what you're asking for is something beyond root's control that can tell
him
"no" when he asks to write to an immutable file.

Hardware would be one such option - a disk which knows what has been written
and will refuse to write over it.

A separate machine would be another, serving up a write-once filesystem over
a
network.

It might even be possible to have two virtual machines on the same box.  
User-mode linux, for instance, lets you create a virtual linux box on a
machine - you have root on the virtual machine, but not necessarily on the
real one.  Obviously, somebody else will have to be the "real" root, and
they'd be able to access the real block devices.  And of course, anybody
that
has physical access to a box can almost certainly gain root on it.

					-J


This e-mail has been captured and archived by the ZANTAZ Digital Safe(tm)
service.  For more information, visit us at www.zantaz.com. 
IMPORTANT: This electronic mail message is intended only for the use of the
individual or entity to which it is addressed and may contain information
that is privileged, confidential or exempt from disclosure under applicable
law.  If the reader of this message is not the intended recipient, or the
employee or agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If you have received
this communication in error, please notify the sender immediately by
telephone or directly reply to the original message(s) sent.  Thank you.

RE: Write-once file system

[Jason Holt]

On Fri, 27 Jun 2003, Fong Vang wrote:

> Physical access to the machine is a separate issue which we're already
> addressing with biometrics and other measures.
> 
> Could root be disabled completely?  I haven't tried this before so I don't
> know what impact disabling root on the system would do.
[...]

*Somebody* has to have root.  Just like *something* on the disk has got to be
physically capable of writing a sector that it shouldn't.  You just need to
construct a machine (speaking abstractly), whether hardware or software, that
can make a proper decision about when it's appropriate to do so.  That machine
needs to be secure against whoever it is you don't trust.

So now you have to define who you'll trust to run that machine, and what you
need non-trusted people to be able to do.  (Even if there was a magic OS or
disk that did exactly what you want, there's still somebody you're trusting -
the person who designed it.)

					-J

Re: Write-once file system

[Russell Coker]

On Sat, 28 Jun 2003 03:37, Jason Holt wrote:
> *Somebody* has to have root.  Just like *something* on the disk has got to
> be physically capable of writing a sector that it shouldn't.  You just need

True.

However if you have a daemon that needs "root" access because it needs raw 
Ethernet access, to bind to low ports, or to spawn child processes under 
different UIDs but which still may not be permitted full access to the system 
then there are a variety of solutions.  SE Linux is the solution I recommend 
to this problem.

If you want a file to not be re-writable in any way (not by any contexts and 
not even by replacing the kernel) then you need some cryptographic solution, 
and AFAIK none of this is available in Linux yet.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Write-once file system

[Jason Holt]

On Sat, 28 Jun 2003, Russell Coker wrote:
[...]
> If you want a file to not be re-writable in any way (not by any contexts and 
> not even by replacing the kernel) then you need some cryptographic solution, 
> and AFAIK none of this is available in Linux yet.
[...]

I don't see why that would be any harder under Linux, or how a CFS really
improves the situation if you assume the hardware's secure.  It goes back to
the access question - you just have to keep a key to the filesystem somewhere
that the kernel can access for bootup, and keep it away from someone trying to
boot into a different kernel.

						-J

Re: Write-once file system

[Mike Young]

Hi Jens,

Interesting idea.  I like it.  I agree with the various comments about
trust, especially as it pertains to administrators.  However, I think at the
very heart of this whole topic is the need to protect against "dubious"
acts.  The latest and greatest security measures and HIPAA acts have a need
for archived, readily accessible, data that cannot be overwritten-- even if
the CFO has a gun to the head of the administrator.

It sounds like this drives towards that end.  It may be stronger than the
requirement, it sure sounds like the direction things are going.  Thanks for
the input on it.

-Mike


On 6/27/03 3:54 PM, "Jens Benecke" <written_030626@jensbenecke.de> wrote:

> On Fri, Jun 27, 2003 at 05:37:05PM +0000, Jason Holt wrote:
> 
>> *Somebody* has to have root.  Just like *something* on the disk has
>> got to be physically capable of writing a sector that it shouldn't.
> 
> <delurk>
> 
> I am using GrSecurity (www.getrewted.net), which is a kernel patch that
> allows detailed ACLs and kernel security enhancements. Once these
> enhancements are configured (at run-time) and "echo 1 >
> /proc/sys/kernel/grsecuity/lock" is executed, it is _not_ possible (even
> for root) to change them again. One of these features is the ability to
> insmod/rmmod, another is the ability to open sockets, another is the
> ability to access raw devices.
> 
> Suppose we have a module that watches over file open calls to the file
> system driver (like the LD_PRELOAD tricks do) and deny write access
> whenever a file already exists.
> 
> 
> Just an idea ... 
> 

Re: Write-once file system

[Jason Holt]

One other thought wrt Mike Young's comments; trust in the enforcement system
could be distributed cryptographically.  Say you go with my suggestion of
user-mode linux running on top of "real" linux which enforces your disk access
policies.  You have auditors observe the setting up of the machine, and
install a script on the "real" side which rotates the "real" root password
periodically to some random value.  It then splits up that password using a
cryptographic secret-splitting algorithm (they're extremely simple) and sends
the pieces to selected individuals.  They all have to get together and agree
to put their pieces together any time you need access to the "real" root
account.

This sort of setup could make a great network appliance for HIPPA shops.

Also,

On Sat, 28 Jun 2003, Jens Benecke wrote:
[...]
> I am using GrSecurity (www.getrewted.net), which is a kernel patch that
> allows detailed ACLs and kernel security enhancements. Once these
> enhancements are configured (at run-time) and "echo 1 >
> /proc/sys/kernel/grsecuity/lock" is executed, it is _not_ possible (even
> for root) to change them again. One of these features is the ability to
> insmod/rmmod, another is the ability to open sockets, another is the
> ability to access raw devices.
[...]

I looked a bit at grsecurity.net, but didn't find anything right off the bat
to explain how they accomplish this securely.  It sounds... really suspicious,
to me anyway.  Do they actually prevent root from, say, manually issuing the
machine code to talk to the disk?  Or does it just keep him from doing it via
the standard syscalls?

						-J

Re: Write-once file system

[Russell Coker]

On Sat, 28 Jun 2003 17:45, Jason Holt wrote:
> I looked a bit at grsecurity.net, but didn't find anything right off the
> bat to explain how they accomplish this securely.  It sounds... really
> suspicious, to me anyway.  Do they actually prevent root from, say,
> manually issuing the machine code to talk to the disk?  Or does it just
> keep him from doing it via the standard syscalls?

They limit what can be done with the system calls.

There is no way of avoiding system calls when accessing things in Linux (*), 
this is the difference between Linux and DOS.

(*) Presuming that you also limit access to /dev/kmem and /dev/mem.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page