[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: zxid session max sub-directories
Eric Rybski wrote:
> I believe zxid currently has a potential Denial of Service
> due to the flat-directory organization of the ses/ session directory.
> ext2/3 has a maximum limit of 32K sub-directories in any one directory.
> Thus if a user were to rapidly initiate multiple new SAML sessions in a
> short period of time, they could max out this limit and cause new sessions
> to fail. This scenario could also occur if zxid were to authenticate many
> different, valid users in a short period of time. Site-specific session
> cleanup scripts would likely not be able to keep up with such a load
> or malicious).
> Has there been consideration of a directory hashing algorithm to store
> session directories? Given a configurable number of directory levels, 2
One way to mitigate this is to use a modern file system that does not have
such low limit on directory entries. Quite frankly I thought ext3 already
did not have this limit. I know for fact that reiserfs, Veritas FS, and
ext4 do not have the limit. I also belive the default filesystem of
Solaris 8 or newer is free from this defect.
> chars per level, and a relatively even distribution of session GUID keys,
> this should dramatically reduce namespace utilization in any one directory
> to eliminate a site-wide DoS attempt, and mitigate the directory limit
> enough for custom session expiration tools (based on a site policy) to
> up with cleanup without ever reaching the max in any sub-directory. (2-3
> sub-levels should be sufficient for most sites.)
Hashing means more complexity and more code, thus more opportunity
Perhaps the same effort could be more productively spent in
writing a true database backend for session management. Ideally
there would be a database independent layer to which plugins
for various databases, such as MySQL, BerkeleyDB, libmm, etc.
> This seems simple enough to implement, assuming there aren't obscure
> to update in the code. Would this be generally limited to cases
> by `egrep "(ZXID_SES_DIR|ses_arch_dir)" *.c` ?
Although I will not personally work towards directory hashing, I am
willing to integrate code by others, provided that the hashing part is
conditioned by #ifded USE_DIR_HASHING or some such.