To be honest, I don't know how secure we can get there because of entry. We only free (without explicitly erasing) the buffers used internally by entry (elm+edje) and textblock, so there might be cleartext copies of the pass in memory anyway...
-- Tom. On 22/08/12 14:30, Carsten Haitzler (The Rasterman) wrote: > On Wed, 22 Aug 2012 12:57:10 +0200 rustyBSD <rusty...@gmx.fr> said: > >> == src/bin/e_desklock.c == >> during auth, user's password may be written >> to disk (core dump). To avoid that, the solution >> is to limit core file size to 0 with|| setrlimit(). The >> problem is that once set to 0, the file size can't >> be raised; so we can't reset the size to the value >> it was before. >> >> Here is a little patch. >> >> Ok or not ? > > this is bad... imho... and well.. it's 0 by default on most linux distros i > know of... but we hurt those that want core dumps. but this is all moot > because... e catches its segv's (thus core dumps). :) > > here's the problem i have with this though.. fine - not in a core dump - but > it > can get swapped out and no one cares :) so it still goes to disk. > > the best thing to do here is to be very pro-active about zeroing out the > passwd > asap so even if u core or swap u dont see it - there is a small window of > opportunty, but only if there is a crash OR someone segv's the process (kill > -SEGV).,. and even if they do seg it.. e catches its segv's aborts, sigbus's > and > doesnt core dump > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
