Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Locking Grid origin identity based on abuse local user account

IP.com Disclosure Number: IPCOM000124574D
Original Publication Date: 2005-Apr-28
Included in the Prior Art Database: 2005-Apr-28
Document File: 3 page(s) / 31K

Publishing Venue

IBM

Abstract

Described is a method to provide account locking, on failed logins, to a Grid authentication process without creating an opening to Denial of Service attacks.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Locking Grid origin identity based on abuse local user account

The problem being solved is that binding the login account locking on failed logins, and the Grid authentication process opens a machine up to Denial of Service (DoS) attacks.

It is possible to configure login accounts such that if a user attempts and fails three times to login the user's account is locked. This is a security measure to prevent hackers from trying brut force login attacks with programs. Even though a user account is locked from login with this feature, it is still possible for the user to gain access through the Grid.

The fix is fairly straightforward: bind the Grid Security Infrastructure (GSI) to the local system login security measures. However, the consequence of doing this is that the machine then exposes itself to a DoS attack, in which a malicious user could simple fail a login 3 times and effectivly shutdown thousands of Grid users. The disclosure idea covers how the binding of the GSI to the local system login security measures can occur and prevent the DoS exposure.

To explain how this could be done and the work around, one first explain the fundamentals of the GSI authentication process.

Grid user are identified by PKCS11 X509 certificates which uniquely identify the user within the name space of the Grid. For example a user may be known as:

C=US/O=IBM/OU=AIX/OU=Grid LPP/CN=John Doe<john_doe@austin.ibm.com> .

When a user signs onto the Grid with their passphrase a X509 proxy certificate is created on the client machine in /tmp/X509<uid of local user>. When the user access a remote resource via the Grid protocol of the client, one sends this proxy certificate over the wire to uniquely identify and authenticate the user to the GSI of the remote resource. The GSI of the remote system must map the client user's Grid identity to a local user. After all, the Grid resource must fork and exec the grid job (a process) and this process must run under a UID. It is this mapping that gives the UID to run the Grid job or process under. This mapping process is quite simple.

The administrator of the Grid resource creates a file /etc/grid-security/grid-mapfile which looks something like:
C=US/O=IBM/OU=AIX/OU=Grid LPP/CN=Shawn Mullen <shawnm@austin.ibm.com>" griduser
C=US/O=IBM/OU=AIX/OU=Grid LPP/CN=Shawn Mullen <shieh@austin.ibm.com>" griduser
C=US/O=IBM/OU=AIX/OU=Grid LPP/CN=Shawn Mullen <sid_malicious@austin.ibm.com>" griduser
C=US/O=IBM/OU=AIX/OU=Grid LPP/CN=Shawn Mullen <keohane@us.ibm.com>" griduser

Note that all three Grid identities map to the same local user "griduser". This is a

1

Page 2 of 3

common pract...