On Mon, 8 May 2000, Jesse Pollard wrote:
> On Tue, 09 May 2000, Benhanokh Gabriel wrote:
> >That sounds dangerously like "security through obscurity", IMO...
> >>
> >> You must not expose the ability to read blocks from disk which have not
> >> been either initialised to zero, or previously written. In effect, the
> >> file must be a copy-on-write area of zeros. Anything else is a security
> >> hole - you can read the contents of deleted files.
> > i don't think it is possible, no users space apps can access the blocks
> >directly, the only way to read is calling system call read which checks for
> >the file size before reading, so if i lock file for writing users can read
> >from it with no problem.
>
> Reading IS where the security violation occurs. Besides, locks are not
> mandatory. Even memory buffers must be initialized, otherwise you can
> extract a LOT of transitory data - private SSL certificates, Kernel
> data (including password file buffers)...
Most crypto implementations I've seen clear the buffers themselves, before
handing the block back to the OS. However, there are very valid reasons
for NEVER allowing ANY process access to uninitialised memory, disk etc.
Apart from anything else, the performance cost is *zero* in the typical
case (allocate block, write to block) since the write goes via a buffer,
which is already initialised to zero. If you try to read from a newly
allocated block, there's something wrong; in this case, the OS will hand
you a page full of zeros, which takes very little time (it's got a list of
pre-prepared zeroed pages handy).
So what are you trying to achieve here?
> >> In which case, the security issue is important - you can't just restrict
> >> this to kernel access only, for example.
> >the allocation service is not going to be offered to user application, i'm
> >going to write it as a module, and only appliactions running with root
> >permissions will be able to call it.
> >
> >> More to the point: why do you want to bypass the security system?
> >because in my case i would be paying too much, for the an overkill.
> >normal appliactions don't care about this zero stuff, since they gonna be
> >overwriting it with their own data which needed to be writen to the disk.
> >so it is only extra memory copy, but in my case the data should never be
> >writen to the disk, so i'm paying with disk access not in memory.
>
> For the most part, it is zero cost (well, a single COW action, which is
> quite fast as it is).
Not even that, usually; most of the time, the OS can just map in an
existing zeroed page. Certainly trivial compared to any disk access...
> If it is a disk buffer then it will (at some time) exist on disk, or
> read from disk. The buffer will contain data that does not belong to
> the process.
Which is completely unacceptable.
We might get even better performance if we hard-wired everyone's UID to
zero, and scrapped those irritating /etc/passwd and /etc/shadow files.
After all, needing to check passwords against the crypt()ed versions takes
CPU time we could use elsewhere...
> >> XFS has been released. It's not in the mainstream kernels yet, but it's
> >> out there.
> >from what i saw it is in a pre-beta stage, which is too early for me to
> >start playing with
>
> XFS won't bypass security either.
Nor will *ANY* sane FS. Obviously OSes such as DOS will do this, but
that's just because they don't have any security or performance
enhancement mechanisms at all...
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:12 EST