Date: 22 Oct 1996 11:38:00 +0100 From: Paul Richards <p.richards@elsevier.co.uk> To: Marc Slemko <marcs@znep.com> Cc: Jason Thorpe <thorpej@nas.nasa.gov>, freebsd-hackers@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c Message-ID: <57loczl1x3.fsf@tees.elsevier.co.uk> In-Reply-To: Marc Slemko's message of Fri, 18 Oct 1996 19:18:49 -0600 (MDT) References: <Pine.BSF.3.95.961018185919.3416F-100000@alive.ampr.ab.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Marc Slemko <marcs@znep.com> writes: > + /* > + * If we are setuid/setgid, or if we've changed uid's in the past, > + * we may be holding privileged information. We must not core! > + */ > if (pcred->p_svuid != pcred->p_ruid || pcred->p_svgid != pcred->p_rgid) > + return (EFAULT); > + if (p->p_flag & P_SUGID) > return (EFAULT); > if (ctob(UPAGES + vm->vm_dsize + vm->vm_ssize) >= > p->p_rlimit[RLIMIT_CORE].rlim_cur) Been thinking about this for a bit. I don't think it's the kernel's job to enforce security of this type. Ok, clarify that, the kernel is correct in not allowing such programs to dump core but it shouldn't be responsible for the problem of ensuring "important" data is not accessible *unless the application requests such a feature*. Not all programs that hold sensitive data need necessarily be run setuid so the above is not that secure. Arbitrarily clearing memory is not a great solution as people have already pointed out, besides, what's stopping me getting access to that memory while the program is running before the memory is freed, say by attaching a debugger. If we were really concerned about securing data within a running application then what we need is a new malloc interface that allows applications to request a secure memory allocation. I'm not sure exactly how it would be implemented but it would be something along the lines of a new mmap option that told the kernel that these pages were in some way secure. It provides interesting possiblities, initially just make sure that those pages are not easily accessible, don't allow attaching processes to access them and have the kernel permanently erase the contents when the process dies or they are returned to the kernel. Maybe we could add some more interesting features in the future, like an encrypted memory manager, if a page isn't accessed within a timeslice then encrypt it using a key specific to that process and then have the kernel decrypt it when the process next accesses that page. This is the sort of thing that would be important to companies that have servers that handle confidential data and they don't even trust their own employees who might have the required access rights to snoop such data. Ok, getting a bit ahead of myself but for those really security concious app developers it would be neat to think up something along these lines. There's zero overhead then for programs that are not required to be secure and it moves the responsibility from the OS designer to the application programmer which is where I believe the responsibility resides. -- Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor) Elsevier Science TIS online journal project. Email: p.richards@elsevier.co.uk Phone: 0370 462071 (Mobile), +44 (0)1865 843155
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57loczl1x3.fsf>