We are submitting this issue to notify you of an IAM policy analysis we conducted based on an October 2021 copy of the cisagov/crossfeed repository. We recognize that your application has continued to change since then, but wanted to share our results with you.
Analyzing backend/serverless.yml in https://github.com/cisagov/crossfeed/tree/fedb7eb, we determined that the provider-level iamRoleStatements definition leads to over-privileged functions -- in other words, more permissions are granted to the function than are necessary to fulfill their task. By looking at the API calls that were actually being made by your application at that time, we determined that the following changes would reduce unnecessary privilege while still permitting the application to function.
High level overview:
Only the api function needed lambda:Invoke, ses:sendRawEmail and s3 permissions. bastion and makeGlobalAdmin functions did not need any permissions. To the best of our knowledge, the scheduler, syncdb, and updateScanTask functions only needed ecs permissions, logs:GetLogEvents, and iam:PassRole permission for running ecs tasks.
src/api/functions.yml:
api:
handler: src/api.handler
events:
- http:
path: / # this matches the base path
method: ANY
cors: true
- http:
path: /{any+} # this matches any path, the token 'any' doesn't mean anything special
method: ANY
cors: true
provisionedConcurrency: 1
iamRoleStatements:
- Effect: Allow
Action:
- lambda:InvokeAsync
- lambda:InvokeFunction
Resource: 'scheduler'
- Effect: Allow
Action:
- ses:SendRawEmail
Resource: '*'
- Effect: Allow
Action:
- s3:GetObject
- s3:GetObjectAcl
- s3:PutObject
- s3:PutObjectAcl
Resource: '*'
- Effect: Allow
Action:
- logs:GetLogEvents
Resource: '*'
- Effect: Allow
Action:
- ecs:RunTask
- ecs:ListTasks
Resource: '*'
- Effect: Allow
Action:
- iam:PassRole
Resource: '*'
Your IAM policy was studied as part of a research project that was conducted jointly by researchers at the North Carolina State University and the University of Illinois at Urbana-Champaign. We developed an algorithm that leveraged graph reachability analysis to inspect privilege in serverless applications. This work has been accepted to appear at the 2024 Web Conference (Paper Title: “GRASP: Hardening Serverless Applications through Graph Reachability Analysis of Security Policies”). We will be discussing the results from our 2021 analysis of your application as part of this work, but will be sure to note that the policy has been updated since then.
Since our analysis, the backend/serverless.yml has added significantly more permissions (e.g., ssm, sts, sqs, and additional logs permissions) to the provider level policy granted to all functions. If you’d like, we’d be happy to update our analysis to reflect the present state of your application. Do let us know if you have any thoughts or feedback.
Best,
Adam Bates (co-authors: Isaac Polinsky, Pubali Datta, Will Enck)
We are submitting this issue to notify you of an IAM policy analysis we conducted based on an October 2021 copy of the
cisagov/crossfeed
repository. We recognize that your application has continued to change since then, but wanted to share our results with you.Analyzing
backend/serverless.yml
in https://github.com/cisagov/crossfeed/tree/fedb7eb, we determined that the provider-leveliamRoleStatements
definition leads to over-privileged functions -- in other words, more permissions are granted to the function than are necessary to fulfill their task. By looking at the API calls that were actually being made by your application at that time, we determined that the following changes would reduce unnecessary privilege while still permitting the application to function.Note: the following policy changes use the https://github.com/functionalone/serverless-iam-roles-per-function serverless plugin to create detailed per-function iam policies.
High level overview: Only the
api
function needed lambda:Invoke,ses:sendRawEmail
ands3
permissions.bastion
andmakeGlobalAdmin
functions did not need any permissions. To the best of our knowledge, thescheduler
,syncdb
, andupdateScanTask
functions only neededecs
permissions,logs:GetLogEvents
, andiam:PassRole
permission for running ecs tasks.src/api/functions.yml
:src/tasks/function.yml
:Your IAM policy was studied as part of a research project that was conducted jointly by researchers at the North Carolina State University and the University of Illinois at Urbana-Champaign. We developed an algorithm that leveraged graph reachability analysis to inspect privilege in serverless applications. This work has been accepted to appear at the 2024 Web Conference (Paper Title: “GRASP: Hardening Serverless Applications through Graph Reachability Analysis of Security Policies”). We will be discussing the results from our 2021 analysis of your application as part of this work, but will be sure to note that the policy has been updated since then.
Since our analysis, the
backend/serverless.yml
has added significantly more permissions (e.g.,ssm
,sts
,sqs
, and additionallogs
permissions) to the provider level policy granted to all functions. If you’d like, we’d be happy to update our analysis to reflect the present state of your application. Do let us know if you have any thoughts or feedback.Best, Adam Bates (co-authors: Isaac Polinsky, Pubali Datta, Will Enck)