* Russell Coker [2004-10-25 19:09]: > On Tue, 19 Oct 2004 06:51, Thomas Bleher > wrote: > > One thing to note here is that restorecon becomes more dangerous with > > your changes. Right now restorecon is relatively safe in that you can > > only change file labels to their system default. It would probably be > > acceptable in most environments to give users access to restorecon so > > they could properly set labels for files in their home dir. > > > > With your changes and this scenario, users could do something like > > restorecon -p /home/foo /home/foo/sbin/unix_chkpwd > > If the user is to run restorecon then they must run it in their own domain. > There is no harm in allowing a user to run restorecon as user_t. They can > only relabel files that have their own identity and a certain set of types. > > Maybe we should even have a script to run restorecon -R on the user's home > directory that they can run at any time if SE Linux stops them doing what > they want? OK, what do you guys think about the following patch: It adds an attribute $1_domain_file_type, so all file types from derived user domains can be grouped together. It also adds a restorecon_domain() macro, so users can call restorecon to reset the labels on their files. It is very lightly tested and probably missing a few permissions but should give a good overview of the general idea. Is such a thing safe? Thomas PS: It may be good to add a password check before restorecon (like newrole does) so we are sure that it's the user who wants to relabel his files. -- http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA D09E C562 2BAE B2F4 ABE7