Security context, how to change?

[Ivan Gyurdiev]

Valdis.Kletnieks at vt.edu wrote:
> On Thu, 13 Oct 2005 07:42:48 +0200, Tomas Larsson said:
>   
>> How do I change the security context automatically.
>> I.e if I am moving one file from one folder, is it possible to automatically
>> to
>> Put the context for the new directory on the file.
>> For example, if I move a file from the FTP-upload folder to HTTPD download
>> folder.
>>     
If you're talking about moving things via shell commands, then using the 
cp command will automatically change the context, if you have sufficient 
rights to do so (read the old context, write the new context, write to 
the folder...etc).
> It may make more sense to create a new context 'user_uploaded_t' or some
> such, and give the FTP server the access needed to write it, and the httpd
> the needed read access.  That way, it gets "sandboxed" and even if it's
> malicious code, nothing else can accidentally read/execute it, so your
> system integrity is enhanced.
>   
A type to taint untrusted content already exists (in strict policy 
anyway, not sure about targeted) - it is called $1_untrusted_content_t. 
This type does not "guard" the content within, so you wouldn't use it to 
target information to be used by a specific program (like, if you wanted 
the information to be available to httpd only, but nothing else). 
Instead, it controls access by all content consumers, based on global 
boolean (read_untrusted_content). Currently, this is used mostly by 
desktop programs, for things like... gpg (signing content), mplayer 
(playing movies), lpr (print stuff), mail programs (upload stuff), 
mozilla client (upload stuff).

Those applications currently use a macro called read_content() to access 
all "trusted" data in /tmp, /home (not what you want), and "untrusted" 
data, if you choose so. You can disable access to reading "untrusted" 
data globally by setting the boolean. In any event, $1_t has { relabelto 
relabelfrom } rights for this type.

My point here is that an appropriate data type exists, IMHO. It might 
have macros for it, designed for a different purpose in mind, but the 
goal of the type is essentially the same (taint malicious data). It's 
also customizable, so the taint persists after restorecon.

I think a lot of this desktop stuff could be further refined to be 
relevant to servers. If we can solve the desktop problem, then the 
server problem becomes easy (desktop is a lot more complicated).
> Depending on your paranoia level, you may or may not want to allow some
> way for a process running in some user_t to un-sandbox the file.  It may be
> sufficient to allow user_t to read it, as there probably shouldn't be any
> automated processes running as user_t - with the implicit "the user is taking
> responsibility for this"...
>   
user_t has { relabelto relabelfrom } rights to the type I was discussing.
Note that you can still revoke user_t's rights to read such content, to 
prevent accidental opening of dangerous files.
user_t keeps { getattr and unlink }.