A small security feature proposition

[Grzegorz Staniak <gstaniak zagiel pl>]

Hi,

I've been reading all the security info on Outlook virii recently,
installing procmail traps for my users, and discussing with friends the
possibility of such threats appearing on Linux (and unices in general).
While the probability of somebody writing an e-mail client that would
lauch executables with a  single click is (hopefully) a remote one, and
it really takes some effort and a lot of stupidity to use '/bin/sh' as
your Netscape viewer for 'application/x-sh', it seems certain that at
some time in the future Linux will be the target of virus attacks of
sorts. Now, I think one could try (apart from educating users and
avoiding risky 'features' in programs) to help users make their valuable
data more secure by using ext2 file attributes and Linux access rights.
What I mean is a smallish graphic utility somewhere on the desktop 
(it would be great if someone added this to graphic filemanagers
too) that would let the user to, say, 'lock/seal/secure this
directory/file' by removing write access (dirs) and executing 'chattr
+i' (files) through a grpahic 'su' wrapper (gsu). In a graphic
manager, such directories/files could be marked in a special way. 
Nothing that you couldn't do from command line, but we're talking about
Joe Newbie here.

Access rights prevent the hypothetical virus from destroying the whole
system, but what counts most for a user is his own data, after all. A
tool like above (or a filemanager feature) would IMVHO go a way towards
avoiding data loss catastrophies, not only virii-related - a mistyped
'rm -f' would also be less dangerous that way. All it would take would
be for the user to 'lock' those directories they can't afford to lose.

What do you think? I've mentioned this on a Mandrake list, and got 
a reply that executing e-mail attachments in a 'chroot' environment 
appears the best way to go (thanks to Dr. Denis Havlik). How is it done
in Evolution? Does it sound feasible to run 'find-requires' on an 
attachment, then find what RPMs the requirements belong to, then copy
the RPMs to a chroot directory before executing them. This could serve 
as an ad-hoc sandbox. And of course this does not exclude the 'sealing'
thingy mentioned above. Comments?

-- 
Grzegorz Staniak <gstaniak@zagiel.pl>