Messages in this thread | | | Date | Tue, 14 May 2002 15:55:04 -0400 | From | Mark Mielke <> | Subject | Re: [RFC] ext2 and ext3 block reservations can be bypassed |
| |
I.e. a fix to ext2/ext3 is not horribly useful.
mark
On Tue, May 14, 2002 at 01:54:40PM -0500, Jesse Pollard wrote: > --------- Received message begins Here --------- > > > > > Don't put /var/log on the same file system as /home, and don't grant > > access to /var/log to any normal userid. > > > > This isn't 'new'. > > Also not relevent. If you want to get picky, don't put root, /usr, /var > and /etc on the same filesystem. Make them all separate. Don't put > /tmp, /var/tmp, on the same filesystem either. Mount /usr read only. > mount / read only, mount all user writable filesystems nosetuid, nosetgid. > > However, not all daemons run as root, but do log into /var/adm or /var/log. > If these fill up the log device without restraint, then your audit logs will > ALSO be affected (unless you have syslog send them to a different host). > > Users don't have to have access to the filesystem to cause write activity > to it. The reserved space is just a small thing. It can't catch everything, > but the system CAN continue to function after the filesystem fills up. > Hopefully, long enough to record events and allow the administrator to > clean up. That is the ONLY security function it has. > > > mark > > > > > > On Tue, May 14, 2002 at 12:53:47PM -0500, Jesse Pollard wrote: > > > If the root file system is ext2, it does become a security issue since > > > currently active logs will continue to record log entries until the > > > filesystem is absolutly filled. I should say, if the log device fills up, > > > since the log directory is usually /var/log, or /var/adm. Some logs show > > > up in etc, but that really depends on the configuration. It IS usefull if the > > > filesystem is "full" due to attacks - daemons tend to terminate themselves, > > > and their log entry indicates what the problem was. If it is an attack, then > > > it's a security issue. > > > > > > The only reason it helps fragmentation (subject to actual implementor > > > statements) is that the filesystem code will use every scavanged block > > > possible under saturation. When the filesystem gets cleand up later, > > > these excessively fragmented files will remain, and continue to cause > > > access delays. > > > > > > Naturally, deleting (or backup/restore) the file(s) cleans up the fragmentation. > > > > > ------------------------------------------------------------------------- > Jesse I Pollard, II > Email: pollard@navo.hpc.mil > > Any opinions expressed are solely my own.
-- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them...
http://mark.mielke.cc/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |