Presentation on theme: "GT4 Architectural Security Review December 17th, 2004."— Presentation transcript:
GT4 Architectural Security Review December 17th, 2004
Policy 2002 (6/5/02) Von Welch 2 Agenda l Welcome. l Goals and Prcoess l GT4 Overview –Von Welch, NCSA l Transport and Message-level Security l Delegation Service –Sam Meder, ANL l GridFTP and RFT –Bill Allock, ANL l GRAM –Von Welch, NCSA l Q&A
Policy 2002 (6/5/02) Von Welch 3 Goals l The goals of a security design review for a Globus Toolkit are: –To receive feedback on the security-related goals of the design. Each Globus Toolkit component has documented security goals that the design attempts to achieve. A goal of the review process is to receive feedback on the appropriateness of the goals. –To receive feedback on how well the design plan achieves those goals. Each Globus Toolkit component should have a documented design.
Policy 2002 (6/5/02) Von Welch 4 Process l We have documents available describing components >http://www-unix.globus.org/security/gt4-review/http://www-unix.globus.org/security/gt4-review/ l This morning we will go through components briefly, allowing for questions to make sure you have a chance to understand goals and designs l We have the afternoon for discussion on pros and cons l We ask you write up your comments on the architecture l We will write a response (agree, disagree, will fix, cant fix, etc.) l Make comments and response available.
Policy 2002 (6/5/02) Von Welch 5 Some Notes l We are going to focus on the default deployment scenarios and very common options l Not intended to be a code-level review l Consider everything said here public
Policy 2002 (6/5/02) Von Welch 6 GT4 Overview GRAM Delegation Service RFT GridFTP Files Job Host Hosting Environment GT4 Clients Transport or Message-level Security Credentials
GT4 GRAM Overview
Policy 2002 (6/5/02) Von Welch 8 Goals of GT4 GRAM Design l Main goal is to minimize consequence of a compromised GRAM service by a remote attacker by minimizing privileges of the GRAM service (and the account in which it runs) –This includes both local and remote privileges
Policy 2002 (6/5/02) Von Welch 9 Goals of GT4 GRAM Design l Usability is also a key goal –Needs to be as simple to deploy and administer as possible l Performance –Reduce latency incurred by key generation for delegation –Reduce round trips by allowing a delegation to be reused for multiple job submissions
Policy 2002 (6/5/02) Von Welch 10 Accounts and Trust Model l The GRAM service runs in a globus account, which has the following privileges: –This account has read access to the host key pair and certificate chain, commonly called the host credential where the certificate is bound to the FQDN of the host system. –Access to all delegated user credentials stored in the DS –The ability to invoke user jobs as defined in sudo policy file –The ability to invoke the globus_receive_delegation application via sudo as any user in order to store credentials in user accounts –It can read the grid-mapfile (which is typically world- readable)
Policy 2002 (6/5/02) Von Welch 11 Sudo l Use third party suid-root program to invoke privileged operations –Hard to get suid-root right –Allow administrator to configure privileges of globus account via sudo configuration
Policy 2002 (6/5/02) Von Welch 12 Sudo l Used to start user jobs –Via globus_authorize_and_execute >Checks to make sure target user is in grid-mapfile as a safety check >Can be replaced at deployment time with local version that does any authorization check desired l Used to transfer delegated credentials to user account >I.e. file owned by user –Via globus_receive_delegation program
Policy 2002 (6/5/02) Von Welch 13 GRAM Walk Through GRAM Delegation Service RFT GridFTP Files Job Host Globus Account GT4 GRAM Client Credentials Sudo User Account