Bug 491227 - Security Officer: An User token can be used to enroll/format another user token.
Security Officer: An User token can be used to enroll/format another user token.
Product: Dogtag Certificate System
Classification: Community
Component: ESC (Show other bugs)
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Jack Magne
Chandrasekar Kannan
Depends On:
Blocks: 443788
  Show dependency treegraph
Reported: 2009-03-19 18:26 EDT by Asha Akkiangady
Modified: 2015-01-04 18:37 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-22 19:33:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Asha Akkiangady 2009-03-19 18:26:58 EDT
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-19 21:32:59 EDT
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-26 21:26:09 EDT
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 17:01:53 EDT
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 17:03:15 EDT
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 17:25:48 EDT
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 19:44:13 EDT
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 13:34:02 EDT
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.