[Top] [All Lists]

Re: Chattr

To: linux-xfs@xxxxxxxxxxx
Subject: Re: Chattr
From: Ethan Benson <erbenson@xxxxxxxxxx>
Date: Tue, 30 Apr 2002 23:26:43 -0800
In-reply-to: <20020501023726.A15270@xxxxxxxxxxxxx>; from ak@xxxxxxx on Wed, May 01, 2002 at 02:37:26AM +0200
Mail-copies-to: nobody
Mail-followup-to: linux-xfs@xxxxxxxxxxx
References: <1020111402.18036.0.camel@UberGeek> <1020174674.24262.0.camel@xxxxxxxxxxxxxxxxxxxx> <20020430062608.M21791@xxxxxxxxxxxxxxx> <1020178382.24279.31.camel@xxxxxxxxxxxxxxxxxxxx> <20020430232706.A28044@xxxxxxxxxxxxx> <20020430143115.O21791@xxxxxxxxxxxxxxx> <20020501014919.A12139@xxxxxxxxxxxxx> <1020210550.1179.3.camel@xxxxxxxxxxxxxxxxxxxxx> <1020211474.1179.6.camel@xxxxxxxxxxxxxxxxxxxxx> <20020501023726.A15270@xxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Wed, May 01, 2002 at 02:37:26AM +0200, Andi Kleen wrote:
> > > Andi, is immutable checking all done above the vfs or do filesystems
> > > have to enforce it as well?
> I think it's done in the file system. 

id have to check but i think i saw some macros used for this in the
VFS layers. look for IS_IMMUTABLE iirc.

> > OK, I answered that myself - maybe we can do this quickly - provided
> > chattr does not check the filesystem type it is applied too.
> I don't think it does. It just does the ioctl. 


eb@dogbert /home/eb$ chattr +i foo
chattr: Inappropriate ioctl for device while reading flags on foo
eb@dogbert /home/eb$ strace chattr +i foo 2>&1 | grep ioctl
ioctl(3, 0x40046601, 0x7ffff918)        = -1 ENOTTY (Inappropriate ioctl for 
write(2, "Inappropriate ioctl for device", 30Inappropriate ioctl for device) = 

> P.S.: Overall I don't think immutable/append-only are too useful because 
> attackers can always get rid of them by mknod'ing a device and writing to the 
> disk directly and forcing an inode flush. So it may not be worth much effort 
> for the pseudo security ones, as they only give a false sense of security. 

this is only because linux' capability system is currently broken, on
*BSD once the secure level is raised root can no longer access raw
devices of mounted filesystems, if you raise it to 2 then all raw disk
devices are blocked.  linux just either needs to add a capability to
restrict access to mounted fs block devices and/or all block devices,
or just deny access when CAP_LINUX_IMMUTABLE (or maybe CAP_SYS_RAWIO) is

in any event its not that hard to fix the hole your describing (and it
didn't exist on 2.0 kernels which used the same securelevel mechenism
as *bsd).

i beleive there is already a patch floating around somewhere to make
linux 2.2+ block raw disk access via some capability.

> immutable is sometimes useful to prevent mistakes, but not for more.

not true, see above.

> The only ones that may be worth it are 'S' (force O_SYNC, especially
> for directories e.g. to handle qmail/postfix spool dirs without forcing
> synchronous for the whole fs), 'A' (no atime) and 'd' for incremental 
> backup purposes.

noatime is not that useful IMO, if your worried about atime updates
there is a mount option, agreed on S(ync).

Ethan Benson

Attachment: pgpJDuefAzfBc.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>