Security context, how to change?

[Daniel J Walsh]

Ivan Gyurdiev wrote:
> 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.
>>  
public_content_rw_t (Formerly ftpd_anon_rw_t) has this characteristic.  
You can set booleans on whether http or ftp and write to it.  All 
sharing apps can read it.  (httpd, ftp, samba, rsync)

> 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 }.
>
> -- 
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list


--