[Swan] [Openswan Users] XAUTH not receiving/computing password

[Nels Lindquist]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/28/2014 3:32 PM, Paul Wouters wrote:
> On Thu, 28 Aug 2014, Nels Lindquist wrote:
> 
>> Subject: Re: [Swan] [Openswan Users] XAUTH not 
>> receiving/computing password
> 
> The odd cause of the problem seems to have been found......
> 
> With selinux in permissive mode:
> 
> 27948 open("/etc/shadow", O_RDONLY|O_CLOEXEC) = 3 27949 
> open("/etc/shadow", O_RDONLY|O_CLOEXEC) = 3 27950 
> open("/etc/shadow", O_RDONLY|O_CLOEXEC) = 3
> 
> With selinux in disabled mode:
> 
> 1623  open("/etc/shadow", O_RDONLY|O_CLOEXEC) = -1 EACCES 
> (Permission denied) 1623  open("/etc/shadow", O_RDONLY|O_CLOEXEC)
> = -1 EACCES (Permission denied)
> 
> I guess we need to file a bug with selinux somewhere?

I don't know enough about SELinux to be sure, but I'm guessing this is
actually "working as designed".  Seems like the default permissions
for /etc/shadow* on other distros and UNIX platforms is 400 rather
than 000.  The latter being a default seems to have been changed in
RHEL6 (RHEL5 still has 400 permissions). I'm thinking this could be an
extrasecurity measure introduced as part of the FIPS compliance stuff
for RHEL6 and higher.

If SELinux provides an alternate (and secure) path for root processes
to access /etc/shadow*, then as long as SELinux is active, having 000
permissions on /etc/shadow* works fine.  The problem arises when you
disable SELinux completely.  Not sure if it's a bug to revert to
standard posix file access when SELinux is disabled, though it could
be argued that restoring sane permissions on system files upon
disabling SELinux would be a nice feature.  One could also argue that
it's a step that should be be taken manually by a SysAdmin who "knows
what they're doing" when they disable SELinux.

On the *other* other hand, the question arises as to why nothing else
appears to have broken except for XAUTH + PAM.  I'd expect more
widesperad (and serious) authentication problems if 000 permissions on
/etc/shadow* is problematic.  Could there be some additional security
parameters or functions needed when pluto is calling the pam library now?


- -- 
Nels Lindquist
<nlindq at maei.ca>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (MingW32)

iEYEARECAAYFAlQAjpcACgkQh6z5POoOLgSHNACeKceWgEzBBMGZUS4dSDnsB4KT
334An21M93HiR7D9Qi9aaN8tk359bVm9
=/sdR
-----END PGP SIGNATURE-----