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/ > 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. -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgp00003.pgp
Description: PGP signature