Bug 755494

What AVC are you seeing?  You are logging in via console or sshd correct?

Ok so you are saying you are using xguest?

yes, I am using xguest

So I do not get any AVC, of course

Are you trying to login in permissive mode?

ps -eZ | grep xguest_t

Also any info in /var/log/secure?

Created attachment 535645 [details]
var/log/secure

and I have no output from:

[root@Acer antonio]# ps -eZ | grep xguest_t
[root@Acer antonio]#

I am running Enforcing

[root@Acer antonio]# getenforce
Enforcing

if I run Selinux as Permissive, I am required of a password even as guest (no idea which password should I issue) then sent back to login screen.

definetely, I think that his bug is connected to failed installation of xguest on fresh systems bugs.

Here I am using a F16 system updated from F15 where xguest could be installed.

 grep xguest /etc/security/sepermit.conf 
xguest:exclusive


yum reinstall xguest

now I can login but screen is not correct, i.e. applications or menus are flashing, at start-up menu characters were not displayed on the screen.

and a silly question: how do I logout from a guest session?? no option available on menus

You should have full menus.

You might want to grab sabayon-apply-2.30.1-3.fc16

yum -y update --enablerepo=updates-testing sabayon-apply

I have found bugs in the application that was causing problems with xguest, but not the ones you are describing.

no improvement, I installed sabayon-apply from updates-testing, I got a bad crash with the standard "something went wrong" and a suggestion to remove some extensions, I removed all extensions, I didn't get any crash but I got the same flashing window.

(In reply to comment #12)
> no improvement, I installed sabayon-apply from updates-testing, I got a bad
> crash with the standard "something went wrong" and a suggestion to remove some
> extensions, I removed all extensions, I didn't get any crash but I got the same
> flashing window.

Same flashing windows for me too. 

xsessions-errors from Bug749970: https://bugzilla.redhat.com/attachment.cgi?id=537911

Are you guys seeing AVC's about xguest?

no AVC's are seen here

(In reply to comment #14)
> Are you guys seeing AVC's about xguest?

None.

Just make sure auditd is enabled.

systemctl enabled auditd.service
systemctl start auditd.service

dmesg | grep avc


Might show them in there.

(In reply to comment #17)
> Just make sure auditd is enabled.
> 
> systemctl enabled auditd.service
> systemctl start auditd.service
> 
> dmesg | grep avc
> 
> 
> Might show them in there.

$ systemctl status auditd.service
auditd.service - Security Auditing Service
	  Loaded: loaded (/lib/systemd/system/auditd.service; enabled)
	  Active: active (running) since Fri, 02 Dec 2011 17:34:55 +0100; 12min ago
	 Process: 916 ExecStartPost=/sbin/auditctl -R /etc/audit/audit.rules (code=exited, status=0/SUCCESS)
	Main PID: 910 (auditd)
	  CGroup: name=systemd:/system/auditd.service
		  ├  910 /sbin/auditd -n
		  ├ 1007 /sbin/audispd
		  └ 1008 /usr/sbin/sedispatch
$ dmesg | grep avc
[   51.226640] dbus[1027]: avc:  netlink poll: error 4
[   51.226686] dbus-daemon[1027]: dbus[1027]: avc:  netlink poll: error 4

Now Gnome 3 works only in fallback mode both for normal user login and for guest login.

I don't think SELinux has anything to do with this.

What does

ausearch -m avc 

return

Created attachment 539759 [details]
ausearch

# setsebool -P allow_xguest_exec_content 1

It looks like we have a fundamental conflict between gnome-shell and xguest ability to lock down content as being both writeable and executable.

Daniel,

starting from a default user, then confined as xguest, Gnome-shell seems work fine.

You mean with 

# setsebool -P allow_xguest_exec_content 1

?

(In reply to comment #24)
> You mean with 
> 
> # setsebool -P allow_xguest_exec_content 1
> 
> ?

No. 

In this way:

# useradd newuser
# passwd newuser
# /usr/sbin/semanage login -a -s xguest_u newuser

so

# /usr/sbin/semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               unconfined_u              s0-s0:c0.c1023           
newuser                   xguest_u                  s0                       
root                      unconfined_u              s0-s0:c0.c1023           
system_u                  system_u                  s0-s0:c0.c1023           
xguest                    xguest_u                  s0

(In reply to comment #24)
> You mean with 
> 
> # setsebool -P allow_xguest_exec_content 1
> 
> ?

No. 

In this way:

# useradd newuser
# passwd newuser
# /usr/sbin/semanage login -a -s xguest_u newuser

so

# /usr/sbin/semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               unconfined_u              s0-s0:c0.c1023           
newuser                   xguest_u                  s0                       
root                      unconfined_u              s0-s0:c0.c1023           
system_u                  system_u                  s0-s0:c0.c1023           
xguest                    xguest_u                  s0

*** Bug 773709 has been marked as a duplicate of this bug. ***

after latest updates I am not able to log as user.

At first, I cannot log in as I get the message about some Authority file for user xguest, then I am requested for a password (that doesn't exists)

Can you reboot or login as root in a terminal and make sure there are no xguest_t processes running?

Kill them and see if you can login as xguest.

with reference to comment 28 the first time I try to log as guest I get

Could not update file /var/lib/xguest/home/.ICEauthority

and does it happen also if you boot in permissive mode adding 

"enforcing=0" 

as kernel parameter.

from a terminal:

[root@Acer ~]# ps aux -Z | grep xguest_t
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 6375 0.0 0.0 4600 804 pts/0 S+ 11:02 0:00 grep --color=auto xguest_t
[root@Acer ~]#

Antonio, run restorecon -R -v /var/lib/xguest

To make sure it is labeled correctly.

enforcing=0 will prevent xguest from logging in.

done, but it is not working.

After running restorecon I got (and I couldn't not login as guest anyway):

ps aux -Z | grep xguest_t
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 3763 0.0  0.0 4604 808 pts/0 S+ 21:37   0:00 grep --color=auto xguest_t

Any message in /var/log/secure?  You are in enforcing mode correct?

Created attachment 557954 [details]
secure (part)

this is the last part of var/log/secure

Not much there.


What login program are you using and does it contain pam_selinux_permit
 grep selinux_permit /etc/pam.d/*
/etc/pam.d/gdm:auth     [success=done ignore=ignore default=bad] pam_selinux_permit.so debug
/etc/pam.d/gdm-password:auth     [success=done ignore=ignore default=bad] pam_selinux_permit.so debug
/etc/pam.d/gnome-screensaver:auth     [success=done ignore=ignore default=bad] pam_selinux_permit.so

# grep selinux_permit /etc/pam.d/*
/etc/pam.d/gdm:auth     [success=done ignore=ignore default=bad] pam_selinux_permit.so
/etc/pam.d/gdm~:auth     [success=done ignore=ignore default=bad] pam_selinux_permit.so
/etc/pam.d/gdm-password:auth     [success=done ignore=ignore default=bad] pam_selinux_permit.so
/etc/pam.d/gdm-password~:auth     [success=done ignore=ignore default=bad] pam_selinux_permit.so
/etc/pam.d/gdm-password.rpmsave:auth     [success=done ignore=ignore default=bad] pam_selinux_permit.so
/etc/pam.d/gdm.rpmsave:auth     [success=done ignore=ignore default=bad] pam_selinux_permit.so
/etc/pam.d/gnome-screensaver:auth     [success=done ignore=ignore default=bad] pam_selinux_permit.so

any additional infos required????

Just to check if this is SELinux blocking or something else.

# semanage permissive -a xguest_t

Then try to login.  This will run xguest in permissive mode.

after comment 39 I can login

Anyway screen is still flashing, i.e. guest account pretty unusable

In a root window, execute
ausearch -m avc -ts recent

ausearch -m avc -ts recent
<no matches>

# semodule -DB
Login as xguest
#semodule -B
Grab all of the AVC messages concerning xguest

Created attachment 557970 [details]
part of avc messages

following your comment

I've got the same problem (impossibility to login) on an up-to-date FC17.
The screen just go back to the login manager (kdm here).
There is no AVC denials in the log, but a failure is reported for USER_START and USER_END:

type=USER_ACCT msg=audit(1350837599.642:3577): pid=18243 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="xguest" exe="/usr/bin/kdm" hostname=? addr=? terminal=:2 res=success'
type=CRED_ACQ msg=audit(1350837599.651:3578): pid=18243 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="xguest" exe="/usr/bin/kdm" hostname=? addr=? terminal=:2 res=success'
type=USER_ROLE_CHANGE msg=audit(1350837599.822:3580): pid=18243 uid=0 auid=512 ses=94 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='pam: default-context=xguest_u:xguest_r:xguest_t:s0 selected-context=xguest_u:xguest_r:xguest_t:s0 exe="/usr/bin/kdm" hostname=? addr=? terminal=? res=success'
type=USER_START msg=audit(1350837599.872:3581): pid=18243 uid=0 auid=512 ses=94 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="xguest" exe="/usr/bin/kdm" hostname=? addr=? terminal=:2 res=failed'
type=USER_END msg=audit(1350837599.891:3582): pid=18243 uid=0 auid=512 ses=94 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct="xguest" exe="/usr/bin/kdm" hostname=? addr=? terminal=:2 res=failed'
type=CRED_DISP msg=audit(1350837599.891:3583): pid=18243 uid=0 auid=512 ses=94 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="xguest" exe="/usr/bin/kdm" hostname=? addr=? terminal=:2 res=success'

I don't know how to investigate this.

Alphonse,
can you log in in permissive mode?

No, I can't, but it is written in the README:

If you put the machine into permissive mode  or disable selinux, you  will no 
longer be able to login as this user.  This will not effect a currently logged 
in user however.  So be very carefull when disableing SELinux.  The logged in XGuest would still be controled by DAC, though.

In this case the log show:

type=USER_AUTH msg=audit(1350909061.050:4027): pid=30714 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="xguest" exe="/usr/bin/kdm" hostname=? addr=? terminal=:2 res=failed'

I thought steps from the comment #39

> Just to check if this is SELinux blocking or something else.

> # semanage permissive -a xguest_t

> Then try to login.  This will run xguest in permissive mode.

Ok. In this case, xguest still cannot login, and the audit log looks like the same as in enforced mode:

type=USER_AUTH msg=audit(1350980365.864:202): pid=4550 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="xguest" exe="/usr/bin/kdm" hostname=? addr=? terminal=:1 res=success'
type=USER_ACCT msg=audit(1350980365.900:203): pid=4550 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="xguest" exe="/usr/bin/kdm" hostname=? addr=? terminal=:1 res=success'
type=CRED_ACQ msg=audit(1350980365.916:204): pid=4550 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="xguest" exe="/usr/bin/kdm" hostname=? addr=? terminal=:1 res=success'
type=LOGIN msg=audit(1350980365.917:205): login pid=4550 uid=0 old auid=4294967295 new auid=512 old ses=4294967295 new ses=6
type=USER_ROLE_CHANGE msg=audit(1350980366.075:206): pid=4550 uid=0 auid=512 ses=6 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='pam: default-context=xguest_u:xguest_r:xguest_t:s0 selected-context=xguest_u:xguest_r:xguest_t:s0 exe="/usr/bin/kdm" hostname=? addr=? terminal=? res=success'
type=USER_START msg=audit(1350980366.203:207): pid=4550 uid=0 auid=512 ses=6 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="xguest" exe="/usr/bin/kdm" hostname=? addr=? terminal=:1 res=failed'
type=USER_END msg=audit(1350980366.221:208): pid=4550 uid=0 auid=512 ses=6 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct="xguest" exe="/usr/bin/kdm" hostname=? addr=? terminal=:1 res=failed'
type=CRED_DISP msg=audit(1350980366.222:209): pid=4550 uid=0 auid=512 ses=6 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="xguest" exe="/usr/bin/kdm" hostname=? addr=? terminal=:1 res=success'


The failure occurs for USER_START & USER_END.

Anything in /var/log/secure?

Good thought!
kdm reports the following three lines at each try:

 kdm: :1[4550]: pam_namespace(kdm:session): Unable to unshare from parent namespace, Operation not permitted
 kdm: :1[4550]: pam_unix(kdm:session): session opened for user xguest by (uid=0)
 kdm: :1[4550]: pam_unix(kdm:session): session closed for user xguest

getsebool -a  | grep poly
polyinstantiation_enabled --> on

$ getsebool -a  | grep poly
allow_polyinstantiation --> off

Setting the boolean to 'on' solve the problem, thanks a lot!
By the way, could you explain the meaning of this boolean?

I wonder why this boolean was not activated, since the command is written in the 
post-install script. The only difference with the other three booleans written in the script is the presence of a trailing space. Is semanage sensible to that?

polyinstatiation means to have multiple views of the same path. In the case of login programs this allows them to use pam_namespace to generate and mount new file systems or directories over /tmp or $HOME.

I have no idea why this was turned off on your machine, since the xguest policy should have turned it on.

The space should not have mattered, although I will remove it.

Thanks for the explanation!
I have installed xguest on another machine, and the boolean was also disabled.
I have found an error message using yum history:

Transaction performed with:
    Installed     rpm-4.9.1.3-7.fc17.x86_64 @updates
    Installed     yum-3.4.3-29.fc17.noarch  @updates
Packages Altered:
    Dep-Install sabayon-apply-2.30.1-4.fc17.x86_64 @fedora
    Install     xguest-1.0.10-4.fc17.noarch        @updates
Scriptlet output:
   1 Traceback (most recent call last):
   2   File "/sbin/semanage", line 566, in <module>
   3     trans.finish()
   4   File "/usr/lib64/python2.7/site-packages/seobject.py", line 285, in finish
   5     self.commit()
   6   File "/usr/lib64/python2.7/site-packages/seobject.py", line 274, in commit
   7     semanage_set_reload(self.sh, self.reload)
   8 TypeError: in method 'semanage_set_reload', argument 2 of type 'int'
history info


I can reproduce the error message with for instance:
# semanage -S targeted -i - << _EOF
user -l xguest_u 
_EOF

Can you yum update policycoreutils

The package is up-to-date for yum.

# rpm -q policycoreutils
policycoreutils-2.1.11-18.fc17.x86_64

Do you mean the one in the testing repo?
Testing it...
# rpm -q policycoreutils
policycoreutils-2.1.12-4.fc17.x86_64

Fixed for the example above (user -l), but I have found another error.
I tried to disable the boolean in order to reinstall xguest and check that it is correctly set after install.
Here the command and the error (I used the same syntax as in the scriptlet):

# semanage -S targeted -i - << _EOF
boolean -m --off allow_polyinstantiation
_EOF
Traceback (most recent call last):
  File "/usr/sbin/semanage", line 568, in <module>
    process_args(mkargv(l))
  File "/usr/sbin/semanage", line 449, in process_args
    OBJECT.modify(target, value, use_file)
  File "/usr/lib64/python2.7/site-packages/seobject.py", line 2026, in modify
    name = selinux.selinux_boolean_sub(name)
AttributeError: 'module' object has no attribute 'selinux_boolean_sub'


By the way, the changelog still refer to 2.1.11.x instead of 2.1.12.x.

Well that is unfortunate.

Try policycoreutils-2.1.12-5.fc17  once it is built.

Fixed!
And after uninstalling xguest and disabling the boolean, it is turned on by the reinstallation.