Re: Write-once file system
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
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
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
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
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:[EMAIL PROTECTED] 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
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:[EMAIL PROTECTED] Sent: Friday, June 27, 2003 10:09 AM To: Fong Vang Cc: 'Oleg Drokin'; 'Hans Reiser'; '[EMAIL PROTECTED]' 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
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
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:[EMAIL PROTECTED] Sent: Friday, June 27, 2003 10:01 AM To: Fong Vang Cc: 'Hans Reiser'; '[EMAIL PROTECTED]' 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
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
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:[EMAIL PROTECTED] Sent: Friday, June 27, 2003 9:20 AM To: Fong Vang Cc: 'Hans Reiser'; '[EMAIL PROTECTED]' 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
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
