Bug 444300 - context system_u:system_r:XXX_unconfined_script_t:s0 is invalid
context system_u:system_r:XXX_unconfined_script_t:s0 is invalid
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-26 15:49 EDT by Robert Scheck
Modified: 2008-05-27 16:07 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-27 16:07:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2008-04-26 15:49:30 EDT
Description of problem:
Apr 26 21:46:11 tux kernel: security:  context
system_u:system_r:httpd_unconfined_script_t:s0-s0:c0.c1023 is invalid
Apr 26 21:46:11 tux kernel: security:  context
system_u:system_r:unconfined_chkpwd_t:s0 is invalid
Apr 26 21:46:11 tux kernel: security:  context
system_u:system_r:httpd_unconfined_script_t:s0 is invalid
Apr 26 21:46:11 tux kernel: security:  context
system_u:system_r:spamassassin_t:s0 is invalid

Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.3.1-42

How reproducible:
Everytime when installing the policy package.

Actual results:
Strange messages.

Expected results:
No strange messages ;-)
Comment 1 Robert Scheck 2008-04-27 04:27:33 EDT
Same happens when I'm trying to execute a third party module where I wrote an
own policy for:

type=SELINUX_ERR msg=audit(1209254004.500:193068): security_compute_sid: 
invalid context unconfined_u:unconfined_r:hp_t:s0-s0:c0.c1023 for
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=system_u:object_r:hp_exec_t:s0 tclass=process
type=SYSCALL msg=audit(1209254004.500:193068): arch=40000003 syscall=11
per=400000 success=yes exit=0 a0=9baa6d0 a1=9baa760 a2=9ba9310 a3=0 items=0
ppid=16276 pid=16277 auid=500 uid=0 gid=100 euid=0 suid=0 fsuid=0 egid=100
sgid=100 fsgid=100 tty=pts3 comm="hplog" exe="/usr/sbin/hplog"
subj=unconfined_u:unconfined_r:hp_t:s0-s0:c0.c1023 key=(null)
Comment 2 Daniel Walsh 2008-04-28 08:50:20 EDT
What is the output of these commands?

# semodule user -l
# semodule login -l
Comment 3 Robert Scheck 2008-04-28 09:54:37 EDT
Hum? I'm pretty sure, that policycoreutils-2.0.46-3 is not absolutely outdated, 
but it doesn't know that command somehow?! Output for your two commands is just
the same as --help.

tux:~ # semodule -l
amavis  1.5.1
amtu    1.1.0
apcupsd 1.3.0
audio_entropy   1.3.0
awstats 1.0.0
bitlbee 1.0.0
calamaris       1.2.0
ccs     1.3.0
cdrecord        1.4.0
certwatch       1.0
cipe    1.4.0
clamav  1.6.0
consolekit      1.3.0
cyphesis        1.0.0
daemontools     1.2.0
dcc     1.5.0
ethereal        1.4.0
evolution       1.2.0
exim    1.0.0
fail2ban        1.1.0
games   1.5.0
gamin   1.0.0
gnome   1.3.0
gnomeclock      1.0.0
gpg     1.5.0
guest   1.0.1
hal     1.9.0
ipsec   1.5.1
irc     1.4.0
iscsid  1.3.1
kerneloops      1.0.0
kismet  1.0.0
local   1.0.0
lockdev 1.2.0
logadm  1.0.0
mailscanner     1.0.0
mozilla 1.5.0
mplayer 1.4.0
mrtg    1.3.0
munin   1.4.0
nagios  1.5.0
nsplugin        1.0.0
nx      1.2.0
oddjob  1.4.0
openct  1.2.0
pcscd   1.3.0
polkit_auth     1.0.0
prelude 1.0.0
publicfile      1.1.0
pyzor   1.5.0
qemu    1.0.0
qmail   1.3.0
razor   1.4.0
ricci   1.3.0
roundup 1.4.0
rpcbind 1.1.0
rwho    1.3.1
screen  1.4.0
slocate 1.6.0
smartmon        1.4.1
soundserver     1.4.0
thunderbird     1.2.0
tmpreaper       1.3.0
tor     1.3.1
tvtime  1.3.0
uml     1.5.0
unconfined      2.1.0
usbmodules      1.1.0
userhelper      1.3.0
usernetctl      1.3.0
virt    1.0.0
vmware  1.4.0
w3c     1.2.1
webadm  1.0.0
xguest  1.0.1
zabbix  1.1.0
tux:~ # 
Comment 4 Robert Scheck 2008-04-28 09:57:17 EDT
Ha, you meant s/semodule/semanage/g:

tux:~ # LANG=C semanage user -l

                Labeling   MLS/       MLS/
SELinux User    Prefix     MCS Level  MCS Range                      SELinux 
Roles

guest_u         guest      s0         s0                             guest_r
root            user       s0         s0-s0:c0.c1023                 system_r 
staff_r unconfined_r sysadm_r
staff_u         user       s0         s0-s0:c0.c1023                 system_r 
staff_r sysadm_r
sysadm_u        user       s0         s0-s0:c0.c1023                 sysadm_r
system_u        user       s0         s0-s0:c0.c1023                 system_r
unconfined_u    unconfined s0         s0-s0:c0.c1023                 system_r 
unconfined_r
user_u          user       s0         s0                             user_r
xguest_u        xguest     s0         s0                             xguest_r
tux:~ # 

tux:~ # LANG=C semanage login -l

Login Name                SELinux User              MLS/MCS Range

__default__               unconfined_u              s0-s0:c0.c1023
root                      root                      s0-s0:c0.c255
system_u                  system_u                  s0-s0:c0.c1023
tux:~ #
Comment 5 Daniel Walsh 2008-05-02 15:17:02 EDT
The policy you wrote youself you need to add

role unconfined_r types hp_t;
 
Similarly I need to add

	role system_r types httpd_unconfined_script_t;

Fixed in selinux-policy-3.3.1-43.fc9

spamassassin_t is a user domain, not a system_r domain?  How did you get this to
happen.


Comment 6 Robert Scheck 2008-05-02 20:30:33 EDT
Very good question. Can it be related with that, that my spamassassin is somehow 
triggered from/within MIMEDefang?
Comment 7 Robert Scheck 2008-05-04 08:14:41 EDT
Sorry, this can't be fixed in selinux-policy-3.3.1-43.fc9, because that one was:

  * Mon Apr 28 2008 Dan Walsh <dwalsh@redhat.com> 3.3.1-43
  - Remove old booleans from targeted-booleans.conf file

which is another of my bug reports ;-) And when using -44, I still see:

May  4 14:13:30 tux kernel: security:  context
unconfined_u:unconfined_r:hp_t:s0-s0:c0.c1023 is invalid
May  4 14:13:30 tux kernel: security:  context
system_u:system_r:httpd_unconfined_script_t:s0-s0:c0.c1023 is invalid
May  4 14:13:30 tux kernel: security:  context
system_u:system_r:unconfined_chkpwd_t:s0 is invalid
May  4 14:13:30 tux kernel: security:  context
system_u:system_r:httpd_unconfined_script_t:s0 is invalid
May  4 14:13:30 tux kernel: security:  context
unconfined_u:unconfined_r:mono_t:s0-s0:c0.c1023 is invalid
May  4 14:13:30 tux kernel: security:  context
unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 is invalid
May  4 14:13:30 tux kernel: security:  context
unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 is invalid
May  4 14:13:31 tux kernel: security:  context
system_u:system_r:spamassassin_t:s0 is invalid
Comment 8 Daniel Walsh 2008-05-06 16:43:57 EDT
Fixed in selinux-policy-3.3.1-45.fc9
Comment 9 Robert Scheck 2008-05-11 06:32:15 EDT
In selinux-policy-3.3.1-49, I'm seeing the following:

May 11 12:30:23 tux kernel: security:  context
system_u:system_r:unconfined_chkpwd_t:s0 is invalid
May 11 12:30:23 tux kernel: security:  context
unconfined_u:unconfined_r:mono_t:s0-s0:c0.c1023 is invalid
May 11 12:30:23 tux kernel: security:  context
unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 is invalid
May 11 12:30:23 tux kernel: security:  context
unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 is invalid
May 11 12:30:23 tux kernel: security:  context
unconfined_u:system_r:spamassassin_t:s0 is invalid
May 11 12:30:23 tux kernel: security:  context
unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 is invalid
May 11 12:30:23 tux kernel: security:  context
system_u:system_r:spamassassin_t:s0 is invalid
May 11 12:30:23 tux kernel: SELinux: policy loaded with 
handle_unknown=allow
Comment 10 Daniel Walsh 2008-05-13 11:48:21 EDT
Robert was this an upgrade from Fedora 8?
Comment 11 Robert Scheck 2008-05-14 03:38:44 EDT
Yes...why? Re-installation is not an option for that box ;-)
Comment 12 Bug Zapper 2008-05-14 06:13:27 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 13 Daniel Walsh 2008-05-14 09:15:23 EDT
Robert I am just trying to figure out why these messages happened.  Most likely
candidate is that the F8 and F9 policy have changed fairly significantly.

For example.

system_u no longer gets to unocnfined_t so
system_u:system_r:unocnfined_chkpwd_t is no longer a valid context.

Similarly 
unconfined_u:unconfined_r:mono_t:s0-s0:c0.c1023 is now
unconfined_u:unconfined_r:unconfined_mono_t:s0-s0:c0.c1023 

Did you upgrade via yum update?


Comment 14 Robert Scheck 2008-05-14 09:46:29 EDT
Yes, yum.
Comment 15 Daniel Walsh 2008-05-16 14:54:08 EDT
Are you continuing to see these messages or was this just during the yum upgrade
from Fedora 8 to Fedora 9?
Comment 16 Robert Scheck 2008-05-17 15:26:48 EDT
Upgrade to selinux-policy-targeted-3.3.1-51 and a reboot reduced the spew only 
to the following (is this my MIMEDefang thing, maybe)?

May 17 21:24:47 tux kernel: security:  context 
system_u:system_r:spamassassin_t:s0 is invalid

I saw these messages all the time, not only during the upgrade.
Comment 17 Robert Scheck 2008-05-21 18:17:09 EDT
selinux-policy-targeted-3.3.1-55 shows me now:

May 22 00:15:23 tux kernel: security:  context 
unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 is invalid
May 22 00:15:24 tux kernel: security:  context 
unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 is invalid
Comment 18 Daniel Walsh 2008-05-23 12:54:26 EDT
How are you generating these errors?
Comment 19 Robert Scheck 2008-05-23 14:33:02 EDT
Well, that's easy: rpm -Uvh selinux-policy-*.rpm --force
Comment 20 Daniel Walsh 2008-05-23 15:15:17 EDT
SO every time you run that you see those errors?
Comment 21 Robert Scheck 2008-05-23 15:22:52 EDT
Yes. Of course they're variing a bit on the policy package you made ;-)
Comment 22 Daniel Walsh 2008-05-24 05:33:44 EDT
Steven ideas?  
Comment 23 Stephen Smalley 2008-05-27 10:45:21 EDT
System must be in permissive mode; in that case, it just warns that the context
is  no longer valid but keeps it around rather than invalidating it and
remapping to unlabeled_t.
We need to avoid these kinds of incompatible policy changes going forward...
Comment 24 Daniel Walsh 2008-05-27 13:39:18 EDT
So you are saying he still has a process running as
unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023?
and
unconfined_u:unconfined_r:groupadd_t:s0-s0:c0.c1023 

This should only be a short run process
Comment 25 Stephen Smalley 2008-05-27 14:01:16 EDT
Doesn't have to be a running process at all.
When a context is first used, a security id (SID) is allocated for it and the
context is stored in the SID table in the kernel, and any later use of the
context re-uses that SID.  Upon policy reload, the SID table is walked to
convert the contexts for the new policy, and any contexts that are no longer
valid under the new policy either cause a warning to be generated (permissive)
or the context to be invalidated and removed (enforcing).  So if you leave the
system in permissive mode, you'll keep getting the warnings on each reload as
they aren't invalidated and removed from the SID table.

Comment 26 Daniel Walsh 2008-05-27 16:07:37 EDT
Ok so setenforce 1/setenforce 0 or reboot should remove this message for ever.

We do not want unconfined_t transitioning to a confined role if possible,
because this is what users expect.  unconfined means unconfined.

Note You need to log in before you can comment on or make changes to this bug.