Bug 491227 - Security Officer: An User token can be used to enroll/format another user token.
Summary: Security Officer: An User token can be used to enroll/format another user token.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Dogtag Certificate System
Classification: Retired
Component: ESC
Version: unspecified
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: Jack Magne
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 443788
TreeView+ depends on / blocked
 
Reported: 2009-03-19 22:26 UTC by Asha Akkiangady
Modified: 2015-01-04 23:37 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-22 23:33:32 UTC
Embargoed:


Attachments (Terms of Use)
Changes to fix this problem. (4.96 KB, patch)
2009-03-28 21:01 UTC, Jack Magne
no flags Details | Diff

Description Asha Akkiangady 2009-03-19 22:26:58 UTC
Description of problem:
An user token can be used to enroll/format another user token. 

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

How reproducible:


Steps to Reproduce:
1. Enroll a security officer token, SOfficer1.
2. Login to Security Officer station with the SOfficer1 token.
3. Enroll a blank token for a user, User1
4. Close the Security officer window. Remove Security officer and user token from the hook.
5. Restart ESC.
6. Provide user User1 token.
7. Provide security password when requested.
8. Security Officer Station UI is shown
9. Click on Enroll a new Card and provide a blank token.
10. Provide valid ldap user name and password, token password.
11. Enrollment is complete.
  
Actual results:
Using user token able to enroll or format another user token.


Expected results:
Only security officer token should be able to enroll/format other tokens.

Additional info:

Comment 1 Jack Magne 2009-03-20 01:32:59 UTC
I suppose this is working because the user token has certificates signed by the same CA as the Security Officer. We might just need to add some further client auth checking to that UI such that only a Security Officer can get through.

Comment 2 Jack Magne 2009-03-27 01:26:09 UTC
There is already code in the cgi's that implement this UI to check to see if a user is actually a Security Officer. If this check fails , the user should not be allowed to proceed to the Security Officer UI. I've already locally gotten this to work properly.

Comment 3 Jack Magne 2009-03-28 21:01:53 UTC
Created attachment 337122 [details]
Changes to fix this problem.

This patch fixes the perl code that is supposed to check to see if a user entering  the Security Officer Workstation UI is actually a security officer. 

n order to make this check meaninful, the Security Officer's ldap user must be placed in the group "TUS Officers" This is usually located under the ldap tree:

cn=TUS Officers,ou=Groups,dc=<hostname>-<tps instance name>

Comment 4 Jack Magne 2009-03-28 21:03:15 UTC
Could we have the documentation for Security Officer mode reflect that the security officers have to be put in a certain group in LDAP as described above?

Comment 6 Matthew Harmsen 2009-03-28 21:25:48 UTC
attachment (id=337122) +mharmsen
- fix SVN conflict in dogtag/tps-ui/shared/cgi-bin/sow/cfg.pl
- go to old license text in base/tps/forms/esc/cgi-bin/sow/cfg.pl
- use mozldap6 for Solaris cases in base/tps/forms/esc/cgi-bin/sow/cfg.pl

Comment 8 Jack Magne 2009-03-28 23:44:13 UTC
svn commit -m "SO officer security fix #491227."
Sending        sow/cfg.pl
Sending        sow/noaccess.html
At revision 343.

Sending        tps-ui/dogtag-pki-tps-ui.spec

Comment 10 Asha Akkiangady 2009-05-28 17:34:02 UTC
Verified that with the user token unable to login to security officer workstation and perform the so functions.


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