Ivan Gyurdiev wrote:
Valdis.Kletnieks@xxxxxx 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
--
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
