Hi folks,

This is more of a curiosity question, and I haven’t found any answer yet.

 

If I receive an AVC and sealert tells me to

   chcon –R –t something_log_t ‘./logs’   with a subsequent semanage

then it goes into file_context.local exactly how I entered it.

 

Cool, I would expect that. But it got me thinking about setfiles/restorecon, and what if I have another directory named logs that requires relabelling?

 

For example, let’s say that today I find incorrect labelling on /somedir/logs and so I fix it with chcon/semanage.

Then next year, I add a new application and it has /anotherdir/logs that is incorrectly labelled. SELinux is going to complain about ./logs again, so I may just cd into /anotherdir and do my chcon/semanage with another_log_t label to this ./logs.

 

That would change the old label, I would think (unless I’m relabelling to the same label), and so now restorecon ./logs will apply the new label to whichever directory I would have to fix.

 

Also, say I actually think about that beforehand and decide to use a full path in my restorecon command -- restorecon –v /somedir/logs -- will it be smart enough to know which logs entry in file_context.local I mean, or do I have to remember that I used a relative path when I created the entry and use that in the restorecon command?

 

So I guess ultimately the question is, wouldn’t it be better for semanage to require full paths?

 

 

Matt Shade

 


This message and any attachment(s) are intended only for the use of the person or entity to which it is addressed and may contain confidential and/or proprietary information.  Any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this message and any attachment(s) by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and delete this message, including any attachments. Sender accepts no liability for any damages caused by any virus transmitted by this e-mail.