Policy Testing Procedures
by Chris Bookholt
Greetings to all,
My systems were also adversely affected (no login, etc.) by the most
recent policy upgrade that came from the official updates-released yum
repository.
What, if any, are the fedora testing procedures for SELinux policy? I
know developers make mistakes, but I thought that's what the development
repos were for.
I don't intend to flame, but rather to express the need for testing to
address the recent flood of policy problems in packages coming from what
are supposed to be reasonably stable repos.
Since I don't see a lack of reliability in other packages coming from
updates-released, it makes me think that the typical
development->test->release cycle does not apply to SELinux policy
packages. If this is the case, why? If not, what other reason is there
for the lack of comparable quality?
Clearly you, the fedora SELinux policy developers, are trying hard to
avoid scaring users away by incrementally tightening the policies.
However, each time a broken policy is released as stable, you lose the
trust you so patiently built.
So, my message is this:
Please test. If you already test, please test more. Thanks for your
hard work and brilliant ideas; I'm a big fan of adding MAC into
mainstream distros.
Best Regards,
Chris
--
Christopher G. Bookholt, RHCE
cgbookho(a)ncsu.edu
17 years, 9 months
Re: SELinux context for data to be shared using both httpd and samba?
by Stephen Smalley
On Mon, 2005-06-27 at 22:02 +0100, Paul Howarth wrote:
> Perhaps this is really a question for the selinux list, but I expect
> someone here must have come across this before.
>
> I've got a software archive sitting on a file server, and this includes
> both Windows software (to be shared out using samba) and a local yum
> repository (to be shared out using httpd).
>
> The SELinux manual tells me to use one set of contexts for sharing data
> using httpd and another set for sharing data using samba. The files can
> each only have one context as far as I know, so how do I resolve this
> conflict without turning off SELinux protection for one of the daemons?
> Add permissions for one daemon to be able to access the other's data?
> What's the way other people handle this?
Define a new type for this purpose, and allow both httpd and samba to
access it. Presently requires installing policy sources, modifying them
accordingly, and rebuilding your policy. Support for policy modules is
coming, but not until FC5.
--
Stephen Smalley
National Security Agency
17 years, 9 months
fc3 selinux-policy-targeted.noarch 1.17.30-3.13 problems?
by Michael W. Carney
Just when I thought the selinux problems were licked, I'm now encountering
problems with gpg, etc after updating with the latest version of targeted
policy:
Details:
60# rpm -q -a selinux-policy-targeted
selinux-policy-targeted-1.17.30-3.13
uname -a
61# uname -a
Linux lucy-01 2.6.11-1.35_FC3smp #1 SMP Mon Jun 13 01:17:35 EDT 2005 i686
i686 i386 GNU/Linux
62#
/var/log/messages (duplicates pruned):
Jun 27 14:08:26 lucy-01 kernel: audit(1119906506.025:0): avc: denied
{ execmod } for pid=5151 comm=X
path=/usr/lib/tls/libnvidia-tls.so.1.0.7174 dev=sdb5 ino=220031
scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:shlib_t
tclass=file
Jun 27 14:08:35 lucy-01 kernel: audit(1119906515.090:0): avc: denied
{ execmod } for pid=5323 comm=kdeinit path=/usr/lib/libmcop.so.1.0.0
dev=sdb5 ino=214284 scontext=user_u:system_r:unconfined_t
tcontext=system_u:object_r:shlib_t tclass=file
Jun 27 14:08:44 lucy-01 kernel: audit(1119906524.703:0): avc: denied
{ execmod } for pid=5410 comm=gpg path=/usr/bin/gpg dev=sdb5 ino=67343
scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:bin_t
tclass=file
Suggestions, please?
17 years, 9 months
unable to login
by rich turner
i am attempting to login as a normal user (fedora core 4) but am
receiving the following error message:
su[1697]:Warning! Could not relabel /dev/console with
user_u:object_r:console_su:/bin/bash:Permission denied
this does not happen when i login as root or when i "setenforce 0".
anyone have any ideas?
i am attempting to login as a normal user (fc4 system) but i am
receiving the following error message:
su[1697]:Warning! Could not relabel /dev/console with
user_u:object_r:console_su:/bin/bash:Permission denied
this does not happen when i login as root or when i "setenforce 0".
i know i will not have any problems if i turn selinux off, but i also
lose the extra security.
anyone have any ideas?
17 years, 9 months
Re: seaudit crashes with segmentation fault
by Stephen Smalley
On Mon, 2005-06-27 at 13:15 -0500, John Bray wrote:
> every time i try to run seaudit, it immediately crashes with a
> segmentation fault. the following errors appear, with or without any
> arguments on the commandline:
>
> [root@junior setools-2.1.0]# seaudit -l /var/log/messages
> -p /etc/selinux/targeted/src/policy/policy.conf
<snip>
>
> wonder if anyone has any ideas or suggestions?
- Post to fedora-selinux-list for SELinux questions.
- What is your base system, FC3 or FC4?
- In FC4, unless you disable auditd, audit messages are sent by the
kernel to auditd and are written by auditd to /var/log/audit/audit.log.
- Not sure that seaudit has been updated for the associated changes.
--
Stephen Smalley
National Security Agency
17 years, 9 months
RE: the labeling procedure
by Steve Brueckner
Stephen Smalley wrote:
> If you want to apply the same contexts, you can use setfiles -r. But
> note that there can be an advantage to using separate types on the
> chroot'd environment, and then not allowing any access by that
> process' domain to the base types used on the real filesystem.
>
> Any chance you can update to FC4?
I've got to release a beta this week so I'm sticking with FC3 at the moment.
I'll certainly upgrade for the next version.
I don't see the -r option in man setfiles. Is it a new option in FC4?
17 years, 9 months
the labeling procedure
by Steve Brueckner
I'm having some problems with some of my filesystem labeling. I'm running
FC3 with the latest SELinux updates (but not rawhide).
When I run #make relabel, /home gets labeled as default_t. However, when I
run #/sbin/restorecon /home, /home gets labeled as home_root_t. This
confuses me, since according to the O'Reilly book both commands refer to
/src/policy/file_contexts/file_contexts. Where else might /sbin/restorecon
be getting its information from?
Furthermore, I notice that /src/policy/file_contexts/file_contexts does not
contain the string home_root_t. I suppose that home_root_t comes from the
homedir_template file during the Make process, but then why doesn't #make
relabel correctly label /home?
I also notice that my context/files/file_contexts file is stale. Doing
#make relabel or #make reload doesn't update it. Does this file ever get
referenced anyway, since all the relabeling utilities seem to use
/src/policy/file_contexts/file_contexts instead? If it does get used, who
uses it? And how can I be sure it gets updated to match
src/policy/file_contexts/file_contexts?
Any help in demystifying the file labeling procedure is appreciated!
Thanks,
Stephen Brueckner, ATC-NY
17 years, 9 months
Deleting file contexts
by Robert Nichols
I'm running with selinux=0 and would like to delete the no longer
updated security contexts from my file systems. Is there a way to
do that short of mke2fs + restore from backup?
--
Bob Nichols Yes, "NOSPAM" is really part of my email address.
17 years, 9 months
SE Linux lacks proper user notification for security violations
by Tracy Reed
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all!
Yesterday I ran into a very odd problem which I think highlights a
serious weakness in the current selinux implementation. A newbie
linux/web developer was testing a perl based cgi on his fedora box. If
he put the cgi progran in /var/www/cgi-bin it would not produce any
output nor error messages. It just seemed to exit. If he ran it from his
~/ it produced the expected output. It took me a good 15 min of
scratching my head over this before I realized this must be an selinux
thing due to the context of the cgi-bin dir and of course I was right.
This highlights a serious concern of mine: Lots of time is being wasted
tracking down strange problems because the only place SE Linux has to
report security errors is in dmesg and the system log. When the cgi
program would not produce any output at all it was not even obvious that
it was a security problem. This is not acceptable for general use. My
users won't think to check the system log for possible security policy
violations relating to their activities and even I often forget to do it
because security policy violation is often not the first thing that
comes to my mind when something like this happens. And even if we do
think of it, we should not have to go check the logs every time
something odd happens suspecting SE Linux. It should be immediately obvious.
Traditionally when there is a security policy violation you get a
"permission denied" on the tty. We have got to find a way to make an
error appear on the tty associated with the process that caused the
violation. I think I am going to look into setting up syslog to log all
such security messages to all tty's until I can find a better solution.
But what is the better solution? I suspect that now that we have a very
granular way of specifying security policy we will need a more granular
way to report errors back to the user.
I am having a rather difficult time selling SE Linux in my business due
to issues like this. People really hate it when this cool new security
feature causes things to fail in dark and mysterious ways. I have been
forced to disable it on all of our machines lest we have a developer
uprising.
- --
Tracy R Reed
http://ultraviolet.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCvRRn9PIYKZYVAq0RAvsvAJ4xRlOfEIcgYPPoVwEKOuRqOr6z7QCfQvcm
XVkZUwoM8+2ot0Neg15RkYA=
=W6Qq
-----END PGP SIGNATURE-----
17 years, 9 months
