udev/sound/alsa: needs to read /var/lib/alsa/asound.state (alsa_var_lib_t)
by Tom London
Running latest rawhide, targeted enforcing.
Booting up, udev (90-alsa.rulles) runs /sbin/salsa to read
/var/lib/alsa/asound.state.
Get these in /var/log/messages:
Sep 25 06:48:13 localhost kernel: audit(1190728078.763:6): avc:
denied { read } for pid=1789 comm="salsa" name="asound.state"
dev=dm-0 ino=688429 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:alsa_var_lib_t:s0 tclass=file
Sep 25 06:55:25 localhost kernel: audit(1190728512.708:5): avc:
denied { getattr } for pid=1793 comm="salsa"
path="/var/lib/alsa/asound.state" dev=dm-0 ino=688429
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:alsa_var_lib_t:s0 tclass=file
tom
[Sorry if I incompletely reported this before, since policy now allows
directory to be read. There was a change in alsa-utils that mistakenly
moved 'salsa' to /bin/salsa, so I stopped gettting AVCs. alsa-utils
fixed now.]
--
Tom London
16 years, 6 months
SELinux problem after sendmail.mc modification.
by Doug Thistlethwaite
Hello,
I hope somebody has seen this before. I am not sure if it is a bug or my
not completely understanding how SELinux works.
My mail server was working fine secured by SELinux running in enforcing
mode. Our company lost connection the the Internet for a couple days so
I edited sendmail.mc to skip the domain check for the duration. I edited
the file ran MAKE and restarted the sendmail process. I also disabled
spamd because all of the email would be internal.
Well SELinux didn't like what I did and started to produce lots of AVC
messages and provided solutions to most of them. I followed the
suggestion in the "Allowing Access" section of the setroubleshoot
browser and most of the messages went away. After about a dozen of these
messages, I decided to just have the system "relabel on next reboot"
using the SELinux management tool. When that didn't fix the problem, I
just disabled SELinux until the Internet connection was fixed.
So the connection was fixed, I fixed the sendmail.mc file to be exactly
the same as before the problem. I used MAKE on the file and relabeled
the SELinux during a reboot and reset SELinux to enforcement mode.
Spamd will not start in enforcement mode. I get the following
setroubleshoot message:
Summary
SELinux is preventing spamd (spamd_t) "search" to mail
(httpd_sys_content_t).
Detailed Description
SELinux denied access requested by spamd. It is not expected that this
access is required by spamd and this access may signal an intrusion
attempt. It is also possible that the specific version or configuration
of the application is causing it to require additional access.
Allowing Access
Sometimes labeling problems can cause SELinux denials. You could try to
restore the default system file context for mail, restorecon -v mail If
this does not work, there is currently no automatic way to allow this
access. Instead, you can generate a local policy module to allow this
access - see FAQ Or you can disable SELinux protection altogether.
Disabling SELinux protection is not recommended. Please file a bug
report against this package.
Additional Information
Source Context: system_u:system_r:spamd_t
Target Context: system_u:object_r:httpd_sys_content_t
Target Objects: mail [ dir ]
Affected RPM Packages:
Policy RPM: selinux-policy-2.6.4-46.fc7
Selinux Enabled: TruePolicy Type: targetedMLS Enabled: True
Enforcing Mode: Permissive
Plugin Name: plugins.catchall_file
When I ran the suggested fix "restorecon -v mail" I get the following
error message:
lstat(mail) failed: No such file or directory
I was under the impression that if I relabeled the system everything
would be reset, but obviously I am incorrect...
I have also received other AVC messages all relating to sendmail files.
I was not sure if these would help so I did not include them in this
message (This questions is already pretty long!).
Any idea how I can get spamd to run in enforcing mode -and- get SELinux
to be happy again?
Thanks,
Doug
16 years, 6 months
BUG? in mkswap (Re: The current status of sebusybox project)
by KaiGai Kohei
Karel,
Can I consider that you are the most appropriate person to report
about the following matter?
The changelog in util-linux-ng.spec says:
| * Wed Mar 8 2006 Karel Zak <kzak(a)redhat.com> 2.13-0.17
| - fix #181782 - mkswap selinux relabeling (fix util-linux-2.13-mkswap-selinux.patch)
> * /sbin/mkswap (should be ported later.)
> - It enables to relabel the target file as "swapfile_t", when we use
> a regular file as a swap.
In util-linux-ng-2.13-1.fc8.src.rpm, this feature is implemented
as follows:
at util-linux-ng-2.13/disk-utils/mkswap.c
-------------------------------------------------------
75 #define SELINUX_SWAPFILE_TYPE "swapfile_t"
: :
735 #ifdef HAVE_LIBSELINUX
736 if (S_ISREG(statbuf.st_mode) && is_selinux_enabled()) {
737 security_context_t context_string;
738 security_context_t oldcontext;
739 context_t newcontext;
740
741 if ((fgetfilecon(DEV, &oldcontext) < 0) &&
742 (errno != ENODATA)) {
743 fprintf(stderr, _("%s: %s: unable to obtain selinux file label: %s\n"),
744 program_name, device_name,
745 strerror(errno));
746 exit(1);
747 }
748 if (!(newcontext = context_new(oldcontext)))
749 die(_("unable to create new selinux context"));
750 if (context_type_set(newcontext, SELINUX_SWAPFILE_TYPE))
751 die(_("couldn't compute selinux context"));
752
753 context_string = context_str(newcontext);
754
755 if (strcmp(context_string, oldcontext)!=0) {
756 if (fsetfilecon(DEV, context_string)) {
757 fprintf(stderr, _("%s: unable to relabel %s to %s: %s\n"),
758 program_name, device_name,
759 context_string,
760 strerror(errno));
761 exit(1);
762 }
763 }
764 context_free(newcontext);
765 freecon(oldcontext);
766 }
767 #endif
-------------------------------------------------------
Pay attention around line 741.
If fgetfilecon() fails and returns -ENODATA, context_new() will be
called with uninitialized oldcontext in the next. Then, it cause
a segmentation fault.
If you don't want to exit immediately, I think this logic can be
changed as follows:
-------------------------------------------------------
if (fgetfilecon(DEV, &oldcontext) < 0) {
if (errno != ENODATA) {
fprintf(stderr, _("%s: %s: unable to obtain selinux file label: %s\n"),
program_name, device_name,
strerror(errno));
exit(1);
}
if (matchpathcon(devide_name, statbuf.st_mode, &oldcontext))
die(_("unable to create new selinux context"));
}
if (!(newcontext = context_new(oldcontext)))
die(_("unable to create new selinux context"));
-------------------------------------------------------
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(a)ak.jp.nec.com>
16 years, 6 months
How to test if SELinux is 'running'
by Tom London
What is the 'approved' method for determining if SELinux is 'running',
that is, active, and in either enforcing or permissive mode?
If my feeble memory serves me, there used to be a 'isSELinux' or some
such, but I can't seem to find this anymore.
I'd like to modify some scripts to work both with and without SELinux
active, e.g., vmware. It is currently testing against the contents of
/selinux/enforce, but that does not seem right....
Thanks,
tom
--
Tom London
16 years, 6 months
Fwd: SELinux is preventing /usr/bin/vlc from changing the access protection of
by Nicolas Chauvet
---------- Forwarded message ----------
From: KH KH <kwizart(a)gmail.com>
Date: 10 oct. 2007 23:49
Subject: Re: SELinux is preventing /usr/bin/vlc from changing the
access protection of
To: Daniel J Walsh <dwalsh(a)redhat.com>
2007/10/10, Daniel J Walsh <dwalsh(a)redhat.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Antonio Olivares wrote:
> Did you read what the troubleshoot told you? It explains pretty much
> your options. You can turn off execheap protection, or you can not run
> the program. You should report this as a bug to the maintainers of vlc.
I'm the maintainer of vlc...(from the mentionned repository).
Well for now, I don't know if this can be fixed without tweaking the code...
I would avoid doing this...unless the only way to solve it...
(read from execheap http://people.redhat.com/drepper/selinux-mem.html)
Others builds was working fine with previous Fedora version (only F-8
seems affected)...
Nicolas (kwizart)
> Follow the links provided by the troubleshooter to find out more about
> execheap.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFHDSpzrlYvE4MpobMRAnwdAKDnMI6TS4J5uaPPduS2ej/Ei7kC0gCfTiMU
> aTOzgTNoH2vgLVT3OYwGa+Q=
> =EsTw
> -----END PGP SIGNATURE-----
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
16 years, 6 months
SELinux is preventing /usr/bin/vlc from changing the access protection of
by Antonio Olivares
memory on the heap
To: fedora-test-list(a)redhat.com
Cc: fedora-selinux-list(a)redhat.com
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <47195.13984.qm(a)web52608.mail.re2.yahoo.com>
Dear all,
I have finished installing vlc from livna-devel repo,
and upon starting it, Selinux setroubleshooter greets
me with the following:
What is a heap? What should I do?
Thanks in Advance,
Antonio
Summary
SELinux is preventing /usr/bin/vlc from changing
the access protection of
memory on the heap.
Detailed Description
The /usr/bin/vlc application attempted to change
the access protection of
memory on the heap (e.g., allocated using malloc).
This is a potential
security problem. Applications should not be
doing this. Applications are
sometimes coded incorrectly and request this
permission. The
http://people.redhat.com/drepper/selinux-mem.html
web page explains how to
remove this requirement. If /usr/bin/vlc does not
work and you need it to
work, you can configure SELinux temporarily to
allow this access until the
application is fixed. Please file a
http://bugzilla.redhat.com/bugzilla/enter_bug.cgi
against this package.
Allowing Access
If you want /usr/bin/vlc to continue, you must
turn on the allow_execheap
boolean. Note: This boolean will affect all
applications on the system.
The following command will allow this access:
setsebool -P allow_execheap=1
Additional Information
Source Context
system_u:system_r:unconfined_t
Target Context
system_u:system_r:unconfined_t
Target Objects None [ process ]
Affected RPM Packages vlc-0.8.6c-5.lvn8
[application]
Policy RPM
selinux-policy-3.0.8-18.fc8
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.allow_execheap
Host Name localhost.localdomain
Platform Linux
localhost.localdomain
2.6.23-0.222.rc9.git4.fc8 #1 SMP Sat Oct 6
13:53:58 EDT 2007 i686
i686
Alert Count 2
First Seen Mon 08 Oct 2007 05:36:54
PM CDT
Last Seen Mon 08 Oct 2007 05:36:55
PM CDT
Local ID
a7f4dbf5-ffcd-472d-b654-8d68c350adad
Line Numbers
Raw Audit Messages
avc: denied { execheap } for comm=wxvlc egid=500
euid=500 exe=/usr/bin/vlc
exit=-13 fsgid=500 fsuid=500 gid=500 items=0 pid=13225
scontext=system_u:system_r:unconfined_t:s0 sgid=500
subj=system_u:system_r:unconfined_t:s0 suid=500
tclass=process
tcontext=system_u:system_r:unconfined_t:s0 tty=(none)
uid=500
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting
16 years, 6 months
Confining TeX
by Jan Kasprzak
Hello,
I am implementing a remote TeX server for our users,
and I would like to confine it using SELinux (FC6, targeted policy).
I need help or suggestions on possible approaches. What I want to do
is the following:
- I have a TeX installation in a separate directory
- I want local users to be able to run TeX commands without restrictions
- I want to have a daemon, running under a separate user, which will handle
remote requests for TeX compilation. Under this user/daemon
the TeX commands should be confined, so that they can only
read TeX data files (the texmf/ tree), execute the TeX sub-commands
(i.e. files under <texroot>/bin/ directory) - including the rights
to the system libraries, locales, etc. as necessary. And the confined
processes should write only to the texmf-var tree (autogenerated
bitmap fonts, etc.) and to the temporary directory, reserved for
TeX outputs (logs, DVI files, dvips outputs, etc.).
My current solution is to create the tex_t domain,
and tex_exec_t, tex_data_t, and tex_tmp_t file types, and make the
daemon run "runcon -t tex_t -- tex myfile.tex" instead of plain
"tex myfile.tex".
Maybe there are better approaches than this:
- maybe the "runcon" is not necessary, and TeX executables can be made to
enter the tex_t domain automatically, when started by the UNIX user
under which the daemon runs.
- or maybe I should use SELinux users or roles instead of domains (?)
- or maybe the daemon should run under its own special domain?
The "runcon" approach allows local users to compile also
untrusted TeX sources - i.e. they can be able to run TeX either under their
own context, or via "runcon" in the confined mode.
Any suggestions?
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ |
> I will never go to meetings again because I think face to face meetings <
> are the biggest waste of time you can ever have. --Linus Torvalds <
16 years, 6 months
SELinux Policy Server
by Sandra Rueda
Hello,
I am interested in the SELinux Policy Server Project that is lead by
Tresys. I looked for information about it and I downloaded the
version of the SELinux Policy Server that is available at
sourceforge.net.
I have some questions regarding the process to build the server:
- The guide indicates that the kernel requires some modifications.
However, by reading the readme files inside the package it looks like
such modifications were required for those kernels that did not
include SELinux by default. Thus fedora core 5 and higher do not
really require such modifications. For recent kernel with SElinux
support I only need to apply the changes to the selinux policy
directory. Is this right?
- It looks like the commands included in the package do not work with
policies higher than 18. The command checkpolicy complains when I try
to compile my reference policy because of the optional policies.
Should I look for older versions of the reference policy?
- Also, the checkpolicy created with the package does not support the
option -M. Does it mean that the current version of the Policy Server
does not support the MLS extension? I know this is a project in
development but in any case I would like to know.
If anyone have answers or comments regarding my questions I would
really appreciate any help.
Thanks,
Sandra
16 years, 6 months
SELinux denies httpd access to /etc/my.cnf
by Anthony Joseph Messina
I get the following in my logs, in permissive mode:
avc: denied { read } for comm="httpd" dev=sda2 egid=48 euid=48
exe="/usr/sbin/httpd" exit=32 fsgid=48 fsuid=48 gid=48 items=0 name="my.cnf"
pid=27369 scontext=root:system_r:httpd_t:s0 sgid=48
subj=root:system_r:httpd_t:s0 suid=48 tclass=file
tcontext=system_u:object_r:mysqld_etc_t:s0 tty=(none) uid=48
avc: denied { getattr } for comm="httpd" dev=sda2 egid=48 euid=48
exe="/usr/sbin/httpd" exit=0 fsgid=48 fsuid=48 gid=48 items=0 name="my.cnf"
path="/etc/my.cnf" pid=27369 scontext=root:system_r:httpd_t:s0 sgid=48
subj=root:system_r:httpd_t:s0 suid=48 tclass=file
tcontext=system_u:object_r:mysqld_etc_t:s0 tty=(none) uid=48
Should httpd be accessing this file? If so, how would I set up that
configuration? It seems that if this type of access is necessary, a boolean
would be in place.
--
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
16 years, 6 months
AVCs on update of selinux-policy-targeted-3.0.8-18.fc8
by Tom London
During today's rawhide update I got the following AVCs during the
update of selinux-policy-targeted-3.0.8-18.fc8:
type=AVC msg=audit(1191690239.759:30): avc: denied { write } for
pid=5397 comm="setsebool" path="pipe:[16633]" dev=pipefs ino=16633
scontext=system_u:system_r:setsebool_t:s0
tcontext=system_u:system_r:rpm_t:s0 tclass=fifo_file
type=AVC msg=audit(1191690239.759:30): avc: denied { write } for
pid=5397 comm="setsebool" path="pipe:[16633]" dev=pipefs ino=16633
scontext=system_u:system_r:setsebool_t:s0
tcontext=system_u:system_r:rpm_t:s0 tclass=fifo_file
type=SYSCALL msg=audit(1191690239.759:30): arch=40000003 syscall=11
success=yes exit=0 a0=93b1dc8 a1=93b1058 a2=93b0bc8 a3=0 items=0
ppid=5396 pid=5397 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=pts0 comm="setsebool" exe="/usr/sbin/setsebool"
subj=system_u:system_r:setsebool_t:s0 key=(null)
No error messages from yum.....
tom
--
Tom London
16 years, 6 months