targeted policy clashes CGI program under apache
by Ben
I'm attempted to use the latest targeted policy under FC3, and while it
generally works well, we're running into some problems when it comes
time to pipe data from PHP into a complex CGI we have. The error we see
is this:
Mar 21 22:17:11 blingbling kernel: audit(1111472231.280:0): avc:
denied { getsched } for pid=405 exe=/var/www/test/cgi-bin/clip
scontext=user_u:system_r:httpd_sys_script_t
tcontext=user_u:system_r:httpd_sys_script_t tclass=process
Apache's error log shows this:
GThread-ERROR **: file gthread-posix.c: line 135 (): error 'Operation
not permitted' during 'pthread_getschedparam (pthread_self(), &policy,
&sched)'aborting...
My CGI does use glib threads; is that a bad thing?
I would like to use SELinux, but there's "like" and "need", and right
now I need to get this working. So, if there's no quick fix, is there a
way to disable SELinux on just this one CGI, do I have to disable it
for all of apache?
19 years, 1 month
Questions about Apache and SELinux context inheritance
by Christofer C. Bell
I have a question about how context inheritance works in SELinux.
The correct file context is already defined in
/etc/selinux/targeted/contexts/files/file_contexts as:
/home/[^/]+/((www)|(web)|(public_html))(/.+)?
system_u:object_r:httpd_user_content_t
However, this context is not inherited when creating a public_html
directory as a user or as root in a user home directory. In
otherwords, when creating a public_html directory, this is what you
get:
drwxrwxr-x cbell cbell user_u:object_r:user_home_t public_html
(I must admit some confusion about the initial user_u user context
since this is not defined in file_contexts). Here you see that the
user context is set to user_u, the role is set to object_r, and the
type is set to user_home_t. This is (in)correctly inherited from the
/home directory's context.
Simply running restorecon -v -R /home/ (as a user or root) will fix
it to read thusly:
drwxrwxr-x cbell cbell system_u:object_r:httpd_user_content_t public_html
At anyrate, the user label is correctly set to system_u, the role is
unchanged with object_r, and the type is changed to
http_user_content_t. This is the context I'd like public_html
directories to automatically assume when created. Is this possible?
Further puzzles:
When creating files in this public_html directory (after resetting the
directory to the correct context) yields more puzzling results:
[cbell@circe public_html]$ touch test
[cbell@circe public_html]$ ls -Z
-rw-rw-r-- cbell cbell user_u:object_r:httpd_sys_content_t test
Note that in this case, the file has been set to user context user_u,
role object_r, and type httpd_sys_content_t. This is the type that's
supposedly reserved for the machine's public web directories:
(from file_contexts)
/var/www(/.*)? system_u:object_r:httpd_sys_content_t
Again, one must run restorecon to correctly set the context on this file to:
-rw-rw-r-- cbell cbell system_u:object_r:httpd_user_content_t test
So my questions are fourfold:
o How can one cause the correct httpd_user_content_t type to be
automatically assigned to user public_html directories (and
subdirectories)?
o How can one cause the correct httpd_user_content_t type to be
automatically assigned to user content (files) in user public_html
directores?
o Why are files initially receiving a user context of user_u rather
than system_u ?
And one file, slightly unrelated question:
o When I installed this server and restored user data to it, the user
context on all the files was set to root rather than user_u (and why
not system_u?). I've reset everything to the correct user context
with chcon, but I'd like to know why this happened.
Thank you all for your insight!
--
Chris
"Build a man a fire and he will be warm for the rest of the night. Set
a man on fire and he will be warm for the rest of his life." -- Unknown
19 years, 1 month
Re: fedora-selinux-list Digest, Vol 13, Issue 16
by Ryan Gall
> > #Context for the driver configuration files
> > /etc/ndiswrapper/ -- system_u:object_r:loadndis_content_t
>
> you probably want this:
>
> /etc/ndiswrapper(/.*)? system_u:object_r:loadndis_content_t
>
> so you can label all of the driver stuff tha'ts stored under that
> directory and it's subdirectories. I don't think your pattern will
> match anything.
>
Actually everything does get the correct labels here. I guess it is
setting the label on the ndiswrapper directory and then all the child
directories and files are inheriting that context.
> > # Filename: loadndis.te
>
> > #Rules for devices
> > allow loadndis_t device_t:dir { rw_dir_perms };
> > allow loadndis_t device_t:chr_file { read create unlink ioctl };
> > allow loadndis_t null_device_t:chr_file { rw_file_perms };
> > allow loadndis_t console_device_t:chr_file { rw_file_perms };
>
> It would be better for the device node to have its own type, and type
> transition the chr_file, that way loadndis_t can only read very specific
> device nodes:
>
> type loadndis_device_t, device_type, dev_fs;
> file_type_auto_trans(loadndis_t,device_t,loadndis_device_t,chr_file)
>
> Or if you really want to go least privilege, you could probably use
> these rules instead of the above file_type_auto_trans:
>
> allow loadndis_t device_t:dir { search write add_name remove_name };
> allow loadndis_t loadndis_device_t:chr_file { read create unlink ioctl };
> type_transition loadndis_t device_t:chr_file loadndis_device_t;
Thanks for the tip. I am assuming here that these transitions cause the
created device to be relabeled to the new loadndis_device_t, which would
then prevent it from messing around with other devices in device_t?
>
> > #Capabilities
> > allow loadndis_t self:capability { sys_tty_config };
> > allow loadndis_t self:capability { mknod };
>
> Just for readability, it would be best to merge these into one line.
> Just a little nitpick. :)
DOH!
>
> > #Rules for proc filesystem
> > allow loadndis_t proc_t:dir { r_dir_perms };
> > allow loadndis_t proc_t:file { r_file_perms };
>
> Another readability thing, you don't need the braces around r_dir_perms
> and r_file_perms, as these are macros, and they already provide braces.
> So the ones you have are redundant.
Thanks for the help Chris.
Ryan
>
> --
> Chris PeBenito
> Tresys Technology, LLC
> (410) 290-1411 x150
>
19 years, 1 month
Fedora Project Mailing Lists reminder
by Elliot Lee
This is a reminder of the mailing lists for the Fedora Project, and
the purpose of each list. You can view this information at
http://fedora.redhat.com/participate/communicate/
When you're using these mailing lists, please take the time to choose
the one that is most appropriate to your post. If you don't know the
right mailing list to use for a question or discussion, please contact
me. This will help you get the best possible answer for your question,
and keep other list subscribers happy!
Mailing Lists
Mailing lists are email addresses which send email to all users
subscribed to the mailing list. Sending an email to a mailing list
reaches all users interested in discussing a specific topic and users
available to help other users with the topic.
The following mailing lists are available. To subscribe, send email to <listname>-request(a)redhat.com
(replace <listname> with the desired mailing list name such as
fedora-list) with the word subscribe in the subject.
fedora-announce-list - Announcements of changes and events. To stay
aware of news, subscribe to this list.
fedora-list - For users of releases. If you want help with a problem
installing or using , this is the list for you.
fedora-test-list - For testers of test releases. If you would like to
discuss experiences using TEST releases, this is the list for you.
fedora-devel-list - For developers, developers, developers. If you are
interested in helping create releases, this is the list for you.
fedora-extras-list - For users and developers of Fedora Extras
fedora-docs-list - For participants of the docs project
fedora-desktop-list - For discussions about desktop issues such as user
interfaces, artwork, and usability
fedora-config-list - For discussions about the development of
configuration tools
fedora-tools-list - For discussions about the toolchain (gcc, gdb,
etc...) within Fedora
fedora-devel-java-list - For discussions about Java-related Fedora
development
fedora-patches-list - For submitting patches to Fedora maintainers, and
used in line with BugWeek
fedora-legacy-announce - For announcements about the Fedora Legacy
Project
fedora-legacy-list - For discussions about the Fedora Legacy Project
fedora-selinux-list - For discussions about the Fedora SELinux Project
fedora-marketing-list - For discussions about marketing and expanding
the Fedora user base
fedora-de-list - For discussions about Fedora in the German language
fedora-es-list - For discussions about Fedora in the Spanish language
fedora-ja-list - For discussions about Fedora in the Japanese language
fedora-i18n-list - For discussions about the internationalization of
Fedora Core
fedora-trans-list - For discussions about translating the software and
documentation associated with the Fedora Project
German: fedora-trans-de
French: fedora-trans-fr
Spanish: fedora-trans-es
Italian: fedora-trans-it
Brazilian Portuguese: fedora-trans-pt_br
Japanese: fedora-trans-ja
Korean: fedora-trans-ko
Simplified Chinese: fedora-trans-zh_cn
Traditional Chinese: fedora-trans-zh_tw
19 years, 1 month
Tweaks to the dovecot policy
by David Hampton
I've added support to the dovecot policy to allow authentication against
a dovecot private password file, and added a couple of tweaks that I
hope tighten up the security of dovecot a little bit. They make the
dovecot configuration file into a unique type, and add a type that can
be used to distinguish mail stored by dovecot from other mail stored on
the system.
David
P.S. These diffs are based on the files from the selinux-policy-strict-
sources-1.22.1-2 rpm on my FC3 system.
19 years, 1 month
SELinux policy for ndiswrapper
by Ryan Gall
I wrote a policy to get ndiswrapper running in my FC3 strict policy SELinux system. This is the first policy I have created. I would greatly appreciate any pointers or feedback anyone would like to share. This policy is specifically used to allow the kernel_t domain to use the loadndisdriver executable to update the ndiswrapper module with configuration information. With this policy I can now successfully insmod ndiswrapper v1.1
#################################################
#
# Define default file contexts for ndis tools
# Filename: loadndis.fc
# Assumptions: This file assumes that the
# loadndisdriver executable is
# found under /sbin and the
# config files are all under
# /etc/ndiswrapper.
#
# Author: Ryan Gall <rrcoot(a)verizon.net>
#
#File context for the loadndisdriver executable
/sbin/loadndisdriver -- system_u:object_r:loadndis_exec_t
#Context for the driver configuration files
/etc/ndiswrapper/ -- system_u:object_r:loadndis_content_t
##################################################
#
# Policy to create a domain for the
# loadndisdriver executable
# Filename: loadndis.te
# Purpose: To isolate the executable to
# some normal application stuff
# and the loadndisdriver configuration
# files. Ultimately allow successful
# completion of `insmod ndiswrapper`
# in an enforcing strict SELinux
# policy.
#
# Author: Ryan Gall <rrcoot(a)verizon.net>
#
#Declare our loadndis domain
type loadndis_t, domain, privlog;
#Let system_r access this new domain
role system_r types loadndis_t;
#Set up the file contexts for loadndis executable and content
type loadndis_exec_t, file_type, sysadmfile;
type loadndis_content_t, file_type, sysadmfile;
#Transition execution to loadndis domain when executed
domain_auto_trans(kernel_t, loadndis_exec_t, loadndis_t)
#Needs to be able to search root of filesystem
allow loadndis_t root_t:dir search;
#Rules for devices
allow loadndis_t device_t:dir { rw_dir_perms };
allow loadndis_t device_t:chr_file { read create unlink ioctl };
allow loadndis_t null_device_t:chr_file { rw_file_perms };
allow loadndis_t console_device_t:chr_file { rw_file_perms };
#Capabilities
allow loadndis_t self:capability { sys_tty_config };
allow loadndis_t self:capability { mknod };
#Rules for proc filesystem
allow loadndis_t proc_t:dir { r_dir_perms };
allow loadndis_t proc_t:file { r_file_perms };
#Sysfs rule
allow loadndis_t sysfs_t:dir { search };
#Allow logging
allow loadndis_t devlog_t:sock_file { write };
#Create a unix datagram socket
allow loadndis_t self:unix_dgram_socket { create_socket_perms };
#Let it access common configuration directories and libraries
uses_shlib(loadndis_t)
read_locale(loadndis_t)
#Finally allow access to our content
allow loadndis_t loadndis_content_t:file { r_file_perms };
allow loadndis_t loadndis_content_t:dir { r_dir_perms };
19 years, 1 month
[newbie] setenforce 1 breaks ~user
by Peter George
I recently upgraded to FC3 + Apache 2.0. from RH7.3 + Apache 1.3. Currently running ext3 filesystem.
/home/*/public_html/ files do not have SELinux extended attributes therefore I cannot change the security context on files.
I cannot see www.domain/~user with # /usr/sbin/setenforce 1 it has to be /usr/sbin/setenforce 0
I know I can force file lelabelling to include extended attributes (forgotten the url with the helpful command just now) with a reboot, and then follow the '# chcon' directives at
http://fedora.redhat.com/docs/selinux-apache-fc3/sn-user-homedir.html
i.e.
# chcon -Rt httpd_sys_content_t /home/*/public_html/
# /usr/sbin/setenforce 1
Any web references or advice appreciated.
P
--
Peter George CIW CI
Training Manager
Net Resources Ltd
26 Palmerston Place, Edinburgh, EH12 5AL
T: 0131 477 7127 F: 0131 477 7126
http://www.netresources.co.uk
19 years, 1 month
Why is --replacepkgs needed?
by susan_geller＠speakeasy.net
I was having some trouble with various audit messages after I upgraded to a newer version of the selinux-policy-targeted rpm. I did
rpm --verify selinux-policy-targeted
and found that several of the files didn't correspond to what is in the rpm.
So I did
rpm -Uvh --replacepkgs ...
and everything magically works.
Why can't the rpm packages be made so that the --replacepkgs flag is not needed?
Thanks, Susan
19 years, 1 month
