Bug 299481 - SELinux issue at smart card login screen
Summary: SELinux issue at smart card login screen
Alias: None
Product: Fedora
Classification: Fedora
Component: coolkey
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bob Relyea
QA Contact: Fedora Extras Quality Assurance
Whiteboard: bzcl34nup
Depends On:
Blocks: 301351
TreeView+ depends on / blocked
Reported: 2007-09-20 23:13 UTC by Jack Magne
Modified: 2008-11-26 17:36 UTC (History)
6 users (show)

Fixed In Version: F8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-11-26 17:36:37 UTC
Type: ---

Attachments (Terms of Use)
SELinux alert report of the issue. (1.97 KB, text/plain)
2007-09-20 23:13 UTC, Jack Magne
no flags Details
SELinux report with latest CoolKey (2.37 KB, text/plain)
2007-09-21 17:21 UTC, Jack Magne
no flags Details
Latest CoolKey SELinux report (2.39 KB, text/plain)
2007-09-21 20:36 UTC, Jack Magne
no flags Details

Description Jack Magne 2007-09-20 23:13:07 UTC
Description of problem:

We have found a case where the SELinux system is issuing a specific error
message when attempting to use a smart card at the login screen.

Originally I thought that this might have bearing on some token detection issues
that we have been having. It turns out that putting SELinux into "Permissive
Mode" does not change this detection behavior. Anyway, it might be useful to
still file this issue in case it is of interest.

When either removing or inserting a smart card at the login screen the following
log message has shown up in the system log:

    SELinux is preventing the gdm-binary from using potentially mislabeled files

Version-Release number of selected component (if applicable):

F8 test2 updated to development as of today 9-20.

How reproducible:


Steps to Reproduce:
1. Configure Fedora for smart card login.
2. Proceed to the login page.
3. Insert an enrolled smart card.
4. Observer the system log on /var/log/messages
5. Notice the above SELinux complaint very close to instances of inserting or
removing the key.  
Actual results:

The presence of a log message of SELinux complaining about access to the
file/directory .pk11ipc1.

Expected results:

If all is well, SELinux should have no reason to complain.

Additional info:

Attachment of the entire report to be enclosed.

Comment 1 Jack Magne 2007-09-20 23:13:07 UTC
Created attachment 201511 [details]
SELinux alert report of the issue.

Comment 2 Bob Relyea 2007-09-20 23:57:35 UTC

If coolkey is trying to access .pk11ipc1, then we need to update it. The latest
version puts the cache in /var/cache/coolkey.


Comment 3 Ray Strode [halfline] 2007-09-21 01:17:43 UTC
So, just to summarize (tell me if I got this wrong)

coolkey at one point, put a cache file in 


since it's in /tmp it doesn't get the proper label

new versions of coolkey use /var/cache/coolkey where it can get a proper label,
but we're shipping old versions.

I'm going to move this to coolkey, so it can get appropriate acks, etc.

Jack, would you mind trying the latest coolkey package to see if you still get
SELinux denial errors?  If so, we may need to clone this bug report to get an
selinux-policy update as well.

Comment 4 Jack Magne 2007-09-21 17:21:06 UTC
Created attachment 202641 [details]
SELinux report with latest CoolKey

Comment 5 Jack Magne 2007-09-21 17:22:48 UTC
I tried a test with the latest compiled (tip) libcoolkeypk11.so dropped in place
and got the following:

    SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "write" to cache (var_t).

The full report is in the post just above.

Comment 6 Ray Strode [halfline] 2007-09-21 17:53:14 UTC
so we need a policy update, Jack, would you mind cloning this bug against

We can keep this report for getting the latest coolkey into the next update, and
have the other report for getting selinux-policy updated to work with the latest

Comment 7 Jack Magne 2007-09-21 18:10:32 UTC
Ray: I can do that no problem.

Bob has informed me that it would be best to run another test on the latest
CoolKey using the full RPM instead of a quick drop-in test. I will do that and
report any different results here.

Comment 8 Jack Magne 2007-09-21 20:33:57 UTC
I was able to do the following:

1. Compile a latest version of the coolkey RPM with the desired cache functionality.

2. Test it on F8.

3. The message we get this time is:

    SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "write" to coolkey

When we get in the updated CoolKey RPM this should be the behavior encountered.

Attachment of the full report on the way.

Comment 9 Jack Magne 2007-09-21 20:36:03 UTC
Created attachment 202801 [details]
Latest CoolKey SELinux report

This attachment shows the latest behavior using an updated test version of
CoolKey. Note that the file/dir being complained about this time is:


Comment 10 Daniel Walsh 2007-09-22 11:22:54 UTC
As of selinux-policy-3.0.8-8 The login programs (xdm, login, sshd ...) will create 

/var/cache/coolkey as auth_cache_t

They can then created files/directories/sockets in this directory

What other daemons need to use this directory?

Comment 11 Jack Magne 2007-09-24 16:58:17 UTC
Thank you.. The only program I witnessed complaining about this problem was
"gdm_binary". Ray and Bob do you think there is potential for other programs
running into this problem?

Comment 12 Bob Relyea 2007-09-24 17:13:01 UTC
esc, plus a bunch of user apps (like firefox/thunberbird/evolution). As crypto
consolidation increases any app that does crypto could potentially hit this


Comment 13 Daniel Walsh 2007-09-24 18:39:46 UTC
These programs would not be allowed to access this directory because of DAC
Controls.  Now they might use a socket if is created in this directory with the
proper permission.

Comment 14 Jack Magne 2007-09-24 20:09:54 UTC
I tested this update with a test (fixed) version of CoolKey which is still being
worked on.  Everything looked fine. No more complaints in the log about about
gdm_binary trying to access a directory that it is not permitted.

Comment 15 Jack Magne 2007-09-28 00:59:12 UTC
Resolved in coolkey build:


Comment 16 Bug Zapper 2008-04-04 13:53:03 UTC
Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.

If this bug still exists in rawhide, please change the version back to
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)

Thanks for your help and we apologize for the interruption.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 17 Bug Zapper 2008-11-26 07:49:54 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 18 Jon Stanley 2008-11-26 17:36:37 UTC
As this bug is in MODIFIED, Fedora believes that a fix has been committed that resolves the problem listed in this bug report.

If this is not the case, please re-open this report, noting the version of the package that you reproduced the bug against.

Thanks for the report!

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