├── .gitignore ├── CODE_OF_CONDUCT.md ├── LICENSE ├── README.md ├── SECURITY.md ├── docs ├── .az-pipelines.yaml ├── assets │ └── diagrams │ │ ├── Activate.svg │ │ ├── CommonParse.svg │ │ ├── Delete.svg │ │ ├── Evaluate.svg │ │ ├── HighLevel.svg │ │ ├── NewPolicy.svg │ │ └── Update.svg ├── attribution.md ├── faq.md ├── index.md ├── license.md ├── presentations.md ├── technical │ ├── diagrams.md │ └── threat-model.md └── usage │ ├── deployment.md │ ├── events.md │ ├── examples.md │ ├── index.md │ └── properties.md └── mkdocs.yml /.gitignore: -------------------------------------------------------------------------------- 1 | ## Ignore Visual Studio temporary files, build results, and 2 | ## files generated by popular Visual Studio add-ons. 3 | ## 4 | ## Get latest from https://github.com/github/gitignore/blob/master/VisualStudio.gitignore 5 | 6 | # User-specific files 7 | *.rsuser 8 | *.suo 9 | *.user 10 | *.userosscache 11 | *.sln.docstates 12 | 13 | # User-specific files (MonoDevelop/Xamarin Studio) 14 | *.userprefs 15 | 16 | # Mono auto generated files 17 | mono_crash.* 18 | 19 | # Build results 20 | [Dd]ebug/ 21 | [Dd]ebugPublic/ 22 | [Rr]elease/ 23 | [Rr]eleases/ 24 | x64/ 25 | x86/ 26 | [Aa][Rr][Mm]/ 27 | [Aa][Rr][Mm]64/ 28 | bld/ 29 | [Bb]in/ 30 | [Oo]bj/ 31 | [Ll]og/ 32 | [Ll]ogs/ 33 | 34 | # Visual Studio 2015/2017 cache/options directory 35 | .vs/ 36 | # Uncomment if you have tasks that create the project's static files in wwwroot 37 | #wwwroot/ 38 | 39 | # Visual Studio 2017 auto generated files 40 | Generated\ Files/ 41 | 42 | # MSTest test Results 43 | [Tt]est[Rr]esult*/ 44 | [Bb]uild[Ll]og.* 45 | 46 | # NUnit 47 | *.VisualState.xml 48 | TestResult.xml 49 | nunit-*.xml 50 | 51 | # Build Results of an ATL Project 52 | [Dd]ebugPS/ 53 | [Rr]eleasePS/ 54 | dlldata.c 55 | 56 | # Benchmark Results 57 | BenchmarkDotNet.Artifacts/ 58 | 59 | # .NET Core 60 | project.lock.json 61 | project.fragment.lock.json 62 | artifacts/ 63 | 64 | # StyleCop 65 | StyleCopReport.xml 66 | 67 | # Files built by Visual Studio 68 | *_i.c 69 | *_p.c 70 | *_h.h 71 | *.ilk 72 | *.meta 73 | *.obj 74 | *.iobj 75 | *.pch 76 | *.pdb 77 | *.ipdb 78 | *.pgc 79 | *.pgd 80 | *.rsp 81 | *.sbr 82 | *.tlb 83 | *.tli 84 | *.tlh 85 | *.tmp 86 | *.tmp_proj 87 | *_wpftmp.csproj 88 | *.log 89 | *.vspscc 90 | *.vssscc 91 | .builds 92 | *.pidb 93 | *.svclog 94 | *.scc 95 | 96 | # Chutzpah Test files 97 | _Chutzpah* 98 | 99 | # Visual C++ cache files 100 | ipch/ 101 | *.aps 102 | *.ncb 103 | *.opendb 104 | *.opensdf 105 | *.sdf 106 | *.cachefile 107 | *.VC.db 108 | *.VC.VC.opendb 109 | 110 | # Visual Studio profiler 111 | *.psess 112 | *.vsp 113 | *.vspx 114 | *.sap 115 | 116 | # Visual Studio Trace Files 117 | *.e2e 118 | 119 | # TFS 2012 Local Workspace 120 | $tf/ 121 | 122 | # Guidance Automation Toolkit 123 | *.gpState 124 | 125 | # ReSharper is a .NET coding add-in 126 | _ReSharper*/ 127 | *.[Rr]e[Ss]harper 128 | *.DotSettings.user 129 | 130 | # TeamCity is a build add-in 131 | _TeamCity* 132 | 133 | # DotCover is a Code Coverage Tool 134 | *.dotCover 135 | 136 | # AxoCover is a Code Coverage Tool 137 | .axoCover/* 138 | !.axoCover/settings.json 139 | 140 | # Visual Studio code coverage results 141 | *.coverage 142 | *.coveragexml 143 | 144 | # NCrunch 145 | _NCrunch_* 146 | .*crunch*.local.xml 147 | nCrunchTemp_* 148 | 149 | # MightyMoose 150 | *.mm.* 151 | AutoTest.Net/ 152 | 153 | # Web workbench (sass) 154 | .sass-cache/ 155 | 156 | # Installshield output folder 157 | [Ee]xpress/ 158 | 159 | # DocProject is a documentation generator add-in 160 | DocProject/buildhelp/ 161 | DocProject/Help/*.HxT 162 | DocProject/Help/*.HxC 163 | DocProject/Help/*.hhc 164 | DocProject/Help/*.hhk 165 | DocProject/Help/*.hhp 166 | DocProject/Help/Html2 167 | DocProject/Help/html 168 | 169 | # Click-Once directory 170 | publish/ 171 | 172 | # Publish Web Output 173 | *.[Pp]ublish.xml 174 | *.azurePubxml 175 | # Note: Comment the next line if you want to checkin your web deploy settings, 176 | # but database connection strings (with potential passwords) will be unencrypted 177 | *.pubxml 178 | *.publishproj 179 | 180 | # Microsoft Azure Web App publish settings. Comment the next line if you want to 181 | # checkin your Azure Web App publish settings, but sensitive information contained 182 | # in these scripts will be unencrypted 183 | PublishScripts/ 184 | 185 | # NuGet Packages 186 | *.nupkg 187 | # NuGet Symbol Packages 188 | *.snupkg 189 | # The packages folder can be ignored because of Package Restore 190 | **/[Pp]ackages/* 191 | # except build/, which is used as an MSBuild target. 192 | !**/[Pp]ackages/build/ 193 | # Uncomment if necessary however generally it will be regenerated when needed 194 | #!**/[Pp]ackages/repositories.config 195 | # NuGet v3's project.json files produces more ignorable files 196 | *.nuget.props 197 | *.nuget.targets 198 | 199 | # Microsoft Azure Build Output 200 | csx/ 201 | *.build.csdef 202 | 203 | # Microsoft Azure Emulator 204 | ecf/ 205 | rcf/ 206 | 207 | # Windows Store app package directories and files 208 | AppPackages/ 209 | BundleArtifacts/ 210 | Package.StoreAssociation.xml 211 | _pkginfo.txt 212 | *.appx 213 | *.appxbundle 214 | *.appxupload 215 | 216 | # Visual Studio cache files 217 | # files ending in .cache can be ignored 218 | *.[Cc]ache 219 | # but keep track of directories ending in .cache 220 | !?*.[Cc]ache/ 221 | 222 | # Others 223 | ClientBin/ 224 | ~$* 225 | *~ 226 | *.dbmdl 227 | *.dbproj.schemaview 228 | *.jfm 229 | *.pfx 230 | *.publishsettings 231 | orleans.codegen.cs 232 | 233 | # Including strong name files can present a security risk 234 | # (https://github.com/github/gitignore/pull/2483#issue-259490424) 235 | #*.snk 236 | 237 | # Since there are multiple workflows, uncomment next line to ignore bower_components 238 | # (https://github.com/github/gitignore/pull/1529#issuecomment-104372622) 239 | #bower_components/ 240 | 241 | # RIA/Silverlight projects 242 | Generated_Code/ 243 | 244 | # Backup & report files from converting an old project file 245 | # to a newer Visual Studio version. Backup files are not needed, 246 | # because we have git ;-) 247 | _UpgradeReport_Files/ 248 | Backup*/ 249 | UpgradeLog*.XML 250 | UpgradeLog*.htm 251 | ServiceFabricBackup/ 252 | *.rptproj.bak 253 | 254 | # SQL Server files 255 | *.mdf 256 | *.ldf 257 | *.ndf 258 | 259 | # Business Intelligence projects 260 | *.rdl.data 261 | *.bim.layout 262 | *.bim_*.settings 263 | *.rptproj.rsuser 264 | *- [Bb]ackup.rdl 265 | *- [Bb]ackup ([0-9]).rdl 266 | *- [Bb]ackup ([0-9][0-9]).rdl 267 | 268 | # Microsoft Fakes 269 | FakesAssemblies/ 270 | 271 | # GhostDoc plugin setting file 272 | *.GhostDoc.xml 273 | 274 | # Node.js Tools for Visual Studio 275 | .ntvs_analysis.dat 276 | node_modules/ 277 | 278 | # Visual Studio 6 build log 279 | *.plg 280 | 281 | # Visual Studio 6 workspace options file 282 | *.opt 283 | 284 | # Visual Studio 6 auto-generated workspace file (contains which files were open etc.) 285 | *.vbw 286 | 287 | # Visual Studio LightSwitch build output 288 | **/*.HTMLClient/GeneratedArtifacts 289 | **/*.DesktopClient/GeneratedArtifacts 290 | **/*.DesktopClient/ModelManifest.xml 291 | **/*.Server/GeneratedArtifacts 292 | **/*.Server/ModelManifest.xml 293 | _Pvt_Extensions 294 | 295 | # Paket dependency manager 296 | .paket/paket.exe 297 | paket-files/ 298 | 299 | # FAKE - F# Make 300 | .fake/ 301 | 302 | # CodeRush personal settings 303 | .cr/personal 304 | 305 | # Python Tools for Visual Studio (PTVS) 306 | __pycache__/ 307 | *.pyc 308 | 309 | # Cake - Uncomment if you are using it 310 | # tools/** 311 | # !tools/packages.config 312 | 313 | # Tabs Studio 314 | *.tss 315 | 316 | # Telerik's JustMock configuration file 317 | *.jmconfig 318 | 319 | # BizTalk build output 320 | *.btp.cs 321 | *.btm.cs 322 | *.odx.cs 323 | *.xsd.cs 324 | 325 | # OpenCover UI analysis results 326 | OpenCover/ 327 | 328 | # Azure Stream Analytics local run output 329 | ASALocalRun/ 330 | 331 | # MSBuild Binary and Structured Log 332 | *.binlog 333 | 334 | # NVidia Nsight GPU debugger configuration file 335 | *.nvuser 336 | 337 | # MFractors (Xamarin productivity tool) working folder 338 | .mfractor/ 339 | 340 | # Local History for Visual Studio 341 | .localhistory/ 342 | 343 | # BeatPulse healthcheck temp database 344 | healthchecksdb 345 | 346 | # Backup folder for Package Reference Convert tool in Visual Studio 2017 347 | MigrationBackup/ 348 | 349 | # Ionide (cross platform F# VS Code tools) working folder 350 | .ionide/ 351 | 352 | # MkDocs Artifacts 353 | site/ 354 | 355 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Microsoft Open Source Code of Conduct 2 | 3 | This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). 4 | 5 | Resources: 6 | 7 | - [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/) 8 | - [Microsoft Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) 9 | - Contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with questions or concerns 10 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Integrity Policy Enforcement (IPE) 4 | 5 | Copyright (c) Microsoft Corporation. 6 | 7 | Permission is hereby granted, free of charge, to any person obtaining a copy 8 | of this software and associated documentation files (the "Software"), to deal 9 | in the Software without restriction, including without limitation the rights 10 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 11 | copies of the Software, and to permit persons to whom the Software is 12 | furnished to do so, subject to the following conditions: 13 | 14 | The above copyright notice and this permission notice shall be included in all 15 | copies or substantial portions of the Software. 16 | 17 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 18 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 19 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 20 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 21 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 22 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 23 | SOFTWARE 24 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | # Contributing 3 | 4 | This project welcomes contributions and suggestions. Most contributions require you to agree to a 5 | Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us 6 | the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com. 7 | 8 | When you submit a pull request, a CLA bot will automatically determine whether you need to provide 9 | a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions 10 | provided by the bot. You will only need to do this once across all repos using our CLA. 11 | 12 | This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). 13 | For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or 14 | contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments. 15 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## Security 4 | 5 | Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include [Microsoft](https://github.com/Microsoft), [Azure](https://github.com/Azure), [DotNet](https://github.com/dotnet), [AspNet](https://github.com/aspnet), [Xamarin](https://github.com/xamarin), and [our GitHub organizations](https://opensource.microsoft.com/). 6 | 7 | If you believe you have found a security vulnerability in any Microsoft-owned repository that meets Microsoft's [Microsoft's definition of a security vulnerability](https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc751383(v=technet.10)) of a security vulnerability, please report it to us as described below. 8 | 9 | ## Reporting Security Issues 10 | 11 | **Please do not report security vulnerabilities through public GitHub issues.** 12 | 13 | Instead, please report them to the Microsoft Security Response Center (MSRC) at [https://msrc.microsoft.com/create-report](https://msrc.microsoft.com/create-report). 14 | 15 | If you prefer to submit without logging in, send email to [secure@microsoft.com](mailto:secure@microsoft.com). If possible, encrypt your message with our PGP key; please download it from the the [Microsoft Security Response Center PGP Key page](https://www.microsoft.com/en-us/msrc/pgp-key-msrc). 16 | 17 | You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Additional information can be found at [microsoft.com/msrc](https://www.microsoft.com/msrc). 18 | 19 | Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue: 20 | 21 | * Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.) 22 | * Full paths of source file(s) related to the manifestation of the issue 23 | * The location of the affected source code (tag/branch/commit or direct URL) 24 | * Any special configuration required to reproduce the issue 25 | * Step-by-step instructions to reproduce the issue 26 | * Proof-of-concept or exploit code (if possible) 27 | * Impact of the issue, including how an attacker might exploit the issue 28 | 29 | This information will help us triage your report more quickly. 30 | 31 | If you are reporting for a bug bounty, more complete reports can contribute to a higher bounty award. Please visit our [Microsoft Bug Bounty Program](https://microsoft.com/msrc/bounty) page for more details about our active programs. 32 | 33 | ## Preferred Languages 34 | 35 | We prefer all communications to be in English. 36 | 37 | ## Policy 38 | 39 | Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https://www.microsoft.com/en-us/msrc/cvd). 40 | 41 | 42 | -------------------------------------------------------------------------------- /docs/.az-pipelines.yaml: -------------------------------------------------------------------------------- 1 | pool: 2 | vmImage: 'ubuntu-18.04' 3 | 4 | trigger: 5 | paths: 6 | include: 7 | - docs/* 8 | 9 | jobs: 10 | - job: BuildDocs 11 | displayName: Build Documentation 12 | dependsOn: [] 13 | steps: 14 | - task: Bash@3 15 | displayName: Install Makedocs 16 | inputs: 17 | targetType: 'inline' 18 | script: | 19 | pip install mkdocs 20 | - task: Bash@3 21 | displayName: Build Site 22 | inputs: 23 | targetType: 'inline' 24 | script: | 25 | python -m mkdocs build -s -d build/ 26 | - task: CopyFiles@2 27 | displayName: Copy Artifacts 28 | inputs: 29 | SourceFolder: build/ 30 | Contents: '**' 31 | TargetFolder: $(Build.ArtifactStagingDirectory) 32 | - task: PublishBuildArtifacts@1 33 | displayName: Publish Artifacts 34 | inputs: 35 | PathToPublish: '$(Build.ArtifactStagingDirectory)' 36 | ArtifactName: 'Doc Site' 37 | publishLocation: 'Container' -------------------------------------------------------------------------------- /docs/assets/diagrams/Activate.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 7 | 8 | 9 | 25 | 26 | 27 | 28 | 29 | 30 | 32 | 33 | 34 | 35 | 36 | Page-1 37 | 38 | 39 | 40 | 41 | Process.1168 42 | /proc/sys/ipe/active_policy 43 | 44 | 46 | 48 | 50 | 52 | 54 | 56 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | /proc/sys/ipe/active_policy 71 | 72 | Data.1169 73 | policy_name 74 | 75 | 77 | 79 | 81 | 83 | 85 | 87 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | policy_name 101 | 102 | Sheet.1283 103 | Userland 104 | 105 | 106 | 107 | Userland 108 | 109 | Sheet.1284 110 | Kernel 111 | 112 | 113 | 114 | Kernel 115 | 116 | Dynamic connector.1172 117 | write() 118 | 119 | 120 | 121 | write() 122 | 123 | Sheet.1286 124 | 125 | 126 | 127 | Process.1174 128 | ipe_lookup_policy_node( name) 129 | 130 | 132 | 134 | 136 | 138 | 140 | 142 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | ipe_lookup_policy_node(name) 157 | 158 | Decision.1175 159 | active_policy == NULL? 160 | 161 | 163 | 165 | 167 | 169 | 171 | 173 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | active_policy == NULL? 188 | 189 | Process.1176 190 | local_ref = node->parsed rcu_swap(local_ref, active_policy) 191 | 192 | 194 | 196 | 198 | 200 | 202 | 204 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | local_ref = node->parsedrcu_swap(local_ref, active_policy) 219 | 220 | Dynamic connector.1179 221 | 222 | 223 | 224 | Dynamic connector.1180 225 | 226 | 227 | 228 | Decision.1181 229 | Node->parsed.version < active_policy.version 230 | 231 | 233 | 235 | 237 | 239 | 241 | 243 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | Node->parsed.version<active_policy.version 258 | 259 | Dynamic connector.1182 260 | FALSE 261 | 262 | 263 | 264 | FALSE 265 | 266 | Dynamic connector.1183 267 | FALSE 268 | 269 | 270 | 271 | FALSE 272 | 273 | Dynamic connector.1184 274 | 275 | 276 | 277 | Start/End.1187 278 | FAIL 279 | 280 | 282 | 284 | 286 | 288 | 290 | 292 | 295 | 296 | 297 | 298 | 299 | 300 | 301 | 302 | 303 | 304 | 306 | FAIL 307 | 308 | Dynamic connector.1188 309 | TRUE 310 | 311 | 312 | 313 | TRUE 314 | 315 | Dynamic connector.1189 316 | TRUE 317 | 318 | 319 | 320 | TRUE 321 | 322 | 323 | -------------------------------------------------------------------------------- /docs/assets/diagrams/Delete.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 29 | 30 | 31 | 32 | 33 | 34 | 36 | 37 | 38 | 39 | 40 | Page-1 41 | 42 | 43 | 44 | 45 | 46 | Process.1130 47 | $securityfs/ipe/del_policy 48 | 49 | 51 | 53 | 55 | 57 | 59 | 61 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | $securityfs/ipe/del_policy 76 | 77 | Data.1131 78 | policy_name 79 | 80 | 82 | 84 | 86 | 88 | 90 | 92 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | policy_name 106 | 107 | Sheet.1323 108 | Userland 109 | 110 | 111 | 112 | Userland 113 | 114 | Sheet.1324 115 | Kernel 116 | 117 | 118 | 119 | Kernel 120 | 121 | Dynamic connector.1146 122 | write() 123 | 124 | 125 | 126 | write() 127 | 128 | Sheet.1326 129 | 130 | 131 | 132 | Process.1149 133 | ipe_lookup_policy_node( name) 134 | 135 | 137 | 139 | 141 | 143 | 145 | 147 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | ipe_lookup_policy_node(name) 162 | 163 | Decision.1152 164 | node == ipe_boot_policy 165 | 166 | 168 | 170 | 172 | 174 | 176 | 178 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | node == ipe_boot_policy 193 | 194 | Process.1153 195 | write_lock(node) 196 | 197 | 199 | 201 | 203 | 205 | 207 | 209 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | write_lock(node) 223 | 224 | Process.1154 225 | ipe_free_private_data 226 | 227 | 229 | 231 | 233 | 235 | 237 | 239 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | ipe_free_private_data 253 | 254 | Process.1155 255 | securityfs_delete_tree( node) write_unlock(node) 256 | 257 | 259 | 261 | 263 | 265 | 267 | 269 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | securityfs_delete_tree(node)write_unlock(node) 285 | 286 | Dynamic connector.1156 287 | 288 | 289 | 290 | Dynamic connector.1157 291 | 292 | 293 | 294 | Decision.1158 295 | is_active_policy( node->i_private) 296 | 297 | 299 | 301 | 303 | 305 | 307 | 309 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | 319 | 320 | 321 | 322 | is_active_policy(node->i_private) 324 | 325 | Dynamic connector.1160 326 | FALSE 327 | 328 | 329 | 330 | FALSE 331 | 332 | Dynamic connector.1161 333 | FALSE 334 | 335 | 336 | 337 | FALSE 338 | 339 | Dynamic connector.1162 340 | 341 | 342 | 343 | Dynamic connector.1163 344 | 345 | 346 | 347 | Dynamic connector.1164 348 | 349 | 350 | 351 | Start/End.1165 352 | FAIL 353 | 354 | 356 | 358 | 360 | 362 | 364 | 366 | 369 | 370 | 371 | 372 | 373 | 374 | 375 | 376 | 377 | 378 | 380 | FAIL 381 | 382 | Dynamic connector.1166 383 | TRUE 384 | 385 | 386 | 387 | TRUE 388 | 389 | Dynamic connector.1167 390 | TRUE 391 | 392 | 393 | 394 | TRUE 395 | 396 | 397 | -------------------------------------------------------------------------------- /docs/assets/diagrams/NewPolicy.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 28 | 29 | 30 | 31 | 32 | 33 | 35 | 36 | 37 | 39 | 40 | 41 | 42 | 43 | Page-1 44 | 45 | 46 | 47 | 48 | 49 | Dynamic connector.34 50 | 1 51 | 52 | 53 | 54 | 1 55 | 56 | Process.33 57 | $securityfs/ipe/new_policy 58 | 59 | 61 | 63 | 65 | 67 | 69 | 71 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | $securityfs/ipe/new_policy 86 | 87 | Data 88 | policy_blob 89 | 90 | 92 | 94 | 96 | 98 | 100 | 102 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | policy_blob 116 | 117 | Dynamic connector.41 118 | 3 119 | 120 | 121 | 122 | 3 123 | 124 | Process.40 125 | Verify_pkcs7_signature 126 | 127 | 129 | 131 | 133 | 135 | 137 | 139 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | Verify_pkcs7_signature 153 | 154 | Dynamic connector.43 155 | 4 156 | 157 | 158 | 159 | 4 160 | 161 | Process.42 162 | alloc_callback() [view inner contents callback] 163 | 164 | 166 | 168 | 170 | 172 | 174 | 176 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | alloc_callback()[view inner contents callback] 191 | 192 | Process.93 193 | ipe_private_inode_data->parsed = policy ipe_private_inode_dat... 194 | 195 | 197 | 199 | 201 | 203 | 205 | 207 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | ipe_private_inode_data->parsed = policyipe_private_inode_data->content =inner_content 223 | 224 | Dynamic connector.94 225 | 7 226 | 227 | 228 | 229 | 7 230 | 231 | Dynamic connector.99 232 | 2 233 | 234 | 235 | 236 | 2 237 | 238 | Process.98 239 | ipe_private_inode_data->raw = policy_blob 240 | 241 | 243 | 245 | 247 | 249 | 251 | 253 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | ipe_private_inode_data->raw =policy_blob 268 | 269 | Process.100 270 | securityfs_create_directory(parsed->name) 271 | 272 | 274 | 276 | 278 | 280 | 282 | 284 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | securityfs_create_directory(parsed->name) 298 | 299 | Process.101 300 | Directory->inode->i_private = ipe_private_data 301 | 302 | 304 | 306 | 308 | 310 | 312 | 314 | 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | Directory->inode->i_private = ipe_private_data 329 | 330 | Dynamic connector.102 331 | 332 | 333 | 334 | Dynamic connector.103 335 | 336 | 337 | 338 | Process.104 339 | 340 | 342 | 344 | 346 | 348 | 350 | 352 | 355 | 356 | 357 | 358 | 359 | 360 | 361 | 362 | 363 | 364 | 365 | Sheet.1051 366 | Userland 367 | 368 | 369 | 370 | Userland 371 | 372 | Sheet.1052 373 | Kernel 374 | 375 | 376 | 377 | Kernel 378 | 379 | Dynamic connector.107 380 | write() 381 | 382 | 383 | 384 | write() 385 | 386 | Process.200 387 | ipe_common_parse 388 | 389 | 391 | 393 | 395 | 397 | 399 | 401 | 404 | 405 | 406 | 407 | 408 | 409 | 410 | 411 | 412 | 413 | 414 | ipe_common_parse 415 | 416 | 417 | -------------------------------------------------------------------------------- /docs/assets/diagrams/Update.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 29 | 30 | 31 | 32 | 33 | 34 | 36 | 37 | 38 | 40 | 41 | 42 | 43 | 44 | Page-1 45 | 46 | 47 | 48 | 49 | 50 | Dynamic connector.115 51 | 1 52 | 53 | 54 | 55 | 1 56 | 57 | Process.116 58 | $securityfs/ipe/$policy/raw 59 | 60 | 62 | 64 | 66 | 68 | 70 | 72 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | $securityfs/ipe/$policy/raw 87 | 88 | Data.117 89 | policy_blob 90 | 91 | 93 | 95 | 97 | 99 | 101 | 103 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | policy_blob 117 | 118 | Dynamic connector.118 119 | 3 120 | 121 | 122 | 123 | 3 124 | 125 | Process.119 126 | Verify_pkcs7_signature 127 | 128 | 130 | 132 | 134 | 136 | 138 | 140 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | Verify_pkcs7_signature 154 | 155 | Process.120 156 | alloc_callback() [view inner contents callback] 157 | 158 | 160 | 162 | 164 | 166 | 168 | 170 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | alloc_callback()[view inner contents callback] 185 | 186 | Process.121 187 | ipe_private_inode_data->parsed = policy ipe_private_inode_dat... 188 | 189 | 191 | 193 | 195 | 197 | 199 | 201 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | ipe_private_inode_data->parsed = policyipe_private_inode_data->content =inner_content 217 | 218 | Dynamic connector.122 219 | 5 220 | 221 | 222 | 223 | 5 224 | 225 | Dynamic connector.123 226 | 2 227 | 228 | 229 | 230 | 2 231 | 232 | Process.124 233 | ipe_private_inode_data->raw = policy_blob 234 | 235 | 237 | 239 | 241 | 243 | 245 | 247 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | ipe_private_inode_data->raw =policy_blob 262 | 263 | Process.125 264 | parsed->policy_name == $policy 265 | 266 | 268 | 270 | 272 | 274 | 276 | 278 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | parsed->policy_name == $policy 292 | 293 | Dynamic connector.127 294 | 6 295 | 296 | 297 | 298 | 6 299 | 300 | Process.129 301 | 302 | 304 | 306 | 308 | 310 | 312 | 314 | 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | Sheet.1020 328 | Userland 329 | 330 | 331 | 332 | Userland 333 | 334 | Sheet.1021 335 | Kernel 336 | 337 | 338 | 339 | Kernel 340 | 341 | Dynamic connector.132 342 | write() 343 | 344 | 345 | 346 | write() 347 | 348 | Process.133 349 | ipe_common_parse 350 | 351 | 353 | 355 | 357 | 359 | 361 | 363 | 366 | 367 | 368 | 369 | 370 | 371 | 372 | 373 | 374 | 375 | 376 | ipe_common_parse 377 | 378 | Dynamic connector.134 379 | 4 380 | 381 | 382 | 383 | 4 384 | 385 | Decision.137 386 | Is_active_policy( $policy) 387 | 388 | 390 | 392 | 394 | 396 | 398 | 400 | 403 | 404 | 405 | 406 | 407 | 408 | 409 | 410 | 411 | 412 | 413 | Is_active_policy($policy) 415 | 416 | Dynamic connector.138 417 | 418 | 419 | 420 | Process.139 421 | rcu_assign_pointer( ipe_private_data->parsed, ipe_active_poli... 422 | 423 | 425 | 427 | 429 | 431 | 433 | 435 | 438 | 439 | 440 | 441 | 442 | 443 | 444 | 445 | 446 | 447 | 448 | rcu_assign_pointer(ipe_private_data->parsed,ipe_active_policy) 451 | 452 | Process.140 453 | swap($policy->i_private, ipe_private_data) 454 | 455 | 457 | 459 | 461 | 463 | 465 | 467 | 470 | 471 | 472 | 473 | 474 | 475 | 476 | 477 | 478 | 479 | 480 | swap($policy->i_private, ipe_private_data) 482 | 483 | Dynamic connector.141 484 | TRUE 485 | 486 | 487 | 488 | TRUE 489 | 490 | Dynamic connector.142 491 | FALSE 492 | 493 | 494 | 495 | FALSE 496 | 497 | Dynamic connector.143 498 | 499 | 500 | 501 | Dynamic connector.144 502 | 503 | 504 | 505 | Process.145 506 | free_old_policy 507 | 508 | 510 | 512 | 514 | 516 | 518 | 520 | 523 | 524 | 525 | 526 | 527 | 528 | 529 | 530 | 531 | 532 | 533 | free_old_policy 534 | 535 | Dynamic connector.146 536 | 537 | 538 | 539 | 540 | -------------------------------------------------------------------------------- /docs/attribution.md: -------------------------------------------------------------------------------- 1 | # Attribution 2 | 3 | This page serves as a way to pay homage to the tools and resources 4 | utilized for the development of IPE and it's supporting features. 5 | 6 | ## [Mkdocs](https://www.mkdocs.org/) 7 | 8 | This package is used to generate these documentation pages. 9 | 10 | ### License 11 | 12 | MkDocs License (BSD) Copyright © 2014, Tom Christie. All rights reserved. Redistribution and use in source and 13 | binary forms, with or without modification, are permitted provided that the following conditions are met: 14 | Redistributions of source code must retain the above copyright notice, this list of conditions and the following 15 | disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and 16 | the following disclaimer in the documentation and/or other materials provided with the distribution. THIS 17 | SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 18 | INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 19 | DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 20 | INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 21 | SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 22 | THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING 23 | IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 24 | -------------------------------------------------------------------------------- /docs/faq.md: -------------------------------------------------------------------------------- 1 | # FAQ 2 | 3 | ### What's the difference between other LSMs which provide integrity verification (i.e. IMA)? 4 | 5 | IPE differs from other LSMs which provide integrity checking, as it has 6 | no dependency on the filesystem metadata itself. The attributes that IPE 7 | checks are deterministic properties that exist solely in the kernel. 8 | Additionally, IPE provides no additional mechanisms of verifying these 9 | files (e.g. IMA Signatures) - all of the attributes of verifying files are 10 | existing features within the kernel. 11 | 12 | Additionally, IPE is completely restricted to integrity. It offers no 13 | measurement or attestation features, which IMA addresses. 14 | 15 | ### Where can I find the code for IPE? 16 | 17 | The IPE LSM code has been submitted for review to the Linux kernel project 18 | [here](https://lore.kernel.org/linux-integrity/?q=Integrity+Policy+Enforcement+LSM+%28IPE%29). 19 | -------------------------------------------------------------------------------- /docs/index.md: -------------------------------------------------------------------------------- 1 | # Integrity Policy Enforcement (IPE) 2 | **Notice:** This website will not be maintained in the future. Please refer to the [latest documentation](https://docs.kernel.org/next/admin-guide/LSM/ipe.html) on kernel.org. 3 | ## Overview 4 | 5 | Integrity Policy Enforcement (IPE) is a Linux Security Module that takes a 6 | complementary approach to access control. Unlike traditional access control 7 | mechanisms that rely on labels and paths for decision-making, IPE focuses 8 | on the immutable security properties inherent to system components. These 9 | properties are fundamental attributes or features of a system component 10 | that cannot be altered, ensuring a consistent and reliable basis for 11 | security decisions. 12 | 13 | To elaborate, in the context of IPE, system components primarily refer to 14 | files or the devices these files reside on. However, this is just a 15 | starting point. The concept of system components is flexible and can be 16 | extended to include new elements as the system evolves. The immutable 17 | properties include the origin of a file, which remains constant and 18 | unchangeable over time. For example, IPE policies can be crafted to trust 19 | files originating from the initramfs. Since initramfs is typically verified 20 | by the bootloader, its files are deemed trustworthy; "file is from 21 | initramfs" becomes an immutable property under IPE's consideration. 22 | 23 | The immutable property concept extends to the security features enabled on 24 | a file's origin, such as dm-verity or fs-verity, which provide a layer of 25 | integrity and trust. For example, IPE allows the definition of policies 26 | that trust files from a dm-verity protected device. dm-verity ensures the 27 | integrity of an entire device by providing a verifiable and immutable state 28 | of its contents. Similarly, fs-verity offers filesystem-level integrity 29 | checks, allowing IPE to enforce policies that trust files protected by 30 | fs-verity. These two features cannot be turned off once established, so 31 | they are considered immutable properties. These examples demonstrate how 32 | IPE leverages immutable properties, such as a file's origin and its 33 | integrity protection mechanisms, to make access control decisions. 34 | 35 | For the IPE policy, specifically, it grants the ability to enforce 36 | stringent access controls by assessing security properties against 37 | reference values defined within the policy. This assessment can be based on 38 | the existence of a security property (e.g., verifying if a file originates 39 | from initramfs) or evaluating the internal state of an immutable security 40 | property. The latter includes checking the roothash of a dm-verity 41 | protected device, determining whether dm-verity possesses a valid 42 | signature, assessing the digest of a fs-verity protected file, or 43 | determining whether fs-verity possesses a valid built-in signature. This 44 | nuanced approach to policy enforcement enables a highly secure and 45 | customizable system defense mechanism, tailored to specific security 46 | requirements and trust models. 47 | 48 | ## What is the value of code integrity? 49 | 50 | Code integrity is identified as one of the most effective security mitigations 51 | for modern systems. With Private Key Infrastructure and code signing you can 52 | effectively control the execution of all binaries on a system to be restricted to 53 | a known subset. This eliminates attacks such as: 54 | 55 | 1. Linker hijacking (LD_PRELOAD, LD_AUDIT, DLL Injection) 56 | 2. Binary rewriting 57 | 3. Malicious binary execution / loading 58 | 59 | As a result, most of the low effort, high value attacks are mitigated completely. 60 | 61 | ## Use Cases 62 | 63 | IPE works best in fixed-function devices: Devices in which their purpose 64 | is clearly defined and not supposed to be changed (e.g. network firewall 65 | device in a data center, an IoT device, etcetera), where all software and 66 | configuration is built and provisioned by the system owner. 67 | 68 | IPE is a long-way off for use in general-purpose computing: the Linux 69 | community as a whole tends to follow a decentralized trust model, 70 | known as the web of trust, which IPE has no support for as of yet. 71 | There are exceptions, such as the case where a Linux distribution 72 | vendor trusts only their own keys, where IPE can successfully be used 73 | to enforce the trust requirement. 74 | 75 | Additionally, while most packages are signed today, the files inside 76 | the packages (for instance, the executables), tend to be unsigned. This 77 | makes it difficult to utilize IPE in systems where a package manager is 78 | expected to be functional, without major changes to the package manager 79 | and ecosystem behind it. 80 | 81 | ## Known Gaps 82 | 83 | 1. IPE cannot verify the integrity of anonymous executable memory, such as 84 | the trampolines created by gcc closures and libffi (<3.4.2), or JIT'd code. 85 | Unfortunately, as this is dynamically generated code, there is no way 86 | for IPE to ensure the integrity of this code to form a trust basis. In all 87 | cases, the return result for these operations will be whatever the admin 88 | configures the DEFAULT action for "EXECUTE". 89 | 90 | 2. IPE cannot verify the integrity of interpreted languages' programs when 91 | these scripts invoked via `` ``. This is because the 92 | way interpreters execute these files, the scripts themselves are not 93 | evaluated as executable code through one of IPE's hooks. Interpreters 94 | can be enlightened to the usage of IPE by trying to mmap a file into 95 | executable memory (+X), after opening the file and responding to the 96 | error code appropriately. This also applies to included files, or high 97 | value files, such as configuration files of critical system components. 98 | -------------------------------------------------------------------------------- /docs/license.md: -------------------------------------------------------------------------------- 1 | # Licensing for IPE 2 | 3 | Per compliance with the Linux kernel's source code license, the **kernel code** of IPE is licensed under the 4 | GPLv2 License. The documentation, test suite, and tools contained within this repository are licensed under the 5 | following license: 6 | 7 | ## License 8 | 9 | Copyright (c) 2020-2024 Microsoft All rights reserved. 10 | 11 | Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated 12 | documentation files (the "Software"), to deal in the Software without restriction, including without limitation 13 | the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and 14 | to permit persons to whom the Software is furnished to do so, subject to the following conditions: 15 | 16 | The above copyright notice and this permission notice shall be included in all copies or substantial portions of 17 | the Software. 18 | 19 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 20 | THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 21 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF 22 | CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS 23 | IN THE SOFTWARE. 24 | -------------------------------------------------------------------------------- /docs/presentations.md: -------------------------------------------------------------------------------- 1 | # Presentations 2 | 3 | ## [Linux Security Summit 2020, North America](https://www.youtube.com/watch?v=wLSREpGQBPI) 4 | 5 | ## [Linux Security Summit 2021](https://www.youtube.com/watch?v=ubmNE_VRWpU) 6 | -------------------------------------------------------------------------------- /docs/technical/diagrams.md: -------------------------------------------------------------------------------- 1 | # Technical Diagrams 2 | 3 | **Note**: these diagrams are out of date, they will be updated once the patchset is accepted by the upstream. 4 | 5 | Left click on any image to view an image in it's original resolution. 6 | As these are SVGs, they will be significantly easier to read when enlarged. 7 | 8 | ## High-Level Architectural 9 | 10 | [![IPE High Level Architectural Diagram](/ipe/assets/diagrams/HighLevel.svg)](/ipe/assets/diagrams/HighLevel.svg) 11 | 12 | ## Common Workflows 13 | 14 | ### Parse Policy 15 | 16 | [![IPE Common Parse Flowchart](/ipe/assets/diagrams/CommonParse.svg)](/ipe/assets/diagrams/CommonParse.svg) 17 | 18 | ## Policy Operations 19 | 20 | ### New Policy 21 | 22 | [![IPE New Policy Flowchart](/ipe/assets/diagrams/NewPolicy.svg)](/ipe/assets/diagrams/NewPolicy.svg) 23 | 24 | ### Update 25 | 26 | [![IPE Update Policy Flowchart](/ipe/assets/diagrams/Update.svg)](/ipe/assets/diagrams/Update.svg) 27 | 28 | ### Delete 29 | 30 | [![IPE Delete Flowchart](/ipe/assets/diagrams/Delete.svg)](/ipe/assets/diagrams/Delete.svg) 31 | 32 | ### Activation 33 | 34 | [![IPE Activate Policy Flowchart](/ipe/assets/diagrams/Activate.svg)](/ipe/assets/diagrams/Activate.svg) 35 | 36 | ## Evaluation 37 | 38 | [![IPE Evaluation Flowchart](/ipe/assets/diagrams/Evaluate.svg)](/ipe/assets/diagrams/Evaluate.svg) 39 | -------------------------------------------------------------------------------- /docs/technical/threat-model.md: -------------------------------------------------------------------------------- 1 | # Threat Model 2 | 3 | IPE specifically targets the risk of tampering with user-space executable 4 | code after the kernel has initially booted, including the kernel modules 5 | loaded from userspace via ``modprobe`` or ``insmod``. 6 | 7 | To illustrate, consider a scenario where an untrusted binary, possibly 8 | malicious, is downloaded along with all necessary dependencies, including a 9 | loader and libc. The primary function of IPE in this context is to prevent 10 | the execution of such binaries and their dependencies. 11 | 12 | IPE achieves this by verifying the integrity and authenticity of all 13 | executable code before allowing them to run. It conducts a thorough 14 | check to ensure that the code's integrity is intact and that they match an 15 | authorized reference value (digest, signature, etc) as per the defined 16 | policy. If a binary does not pass this verification process, either 17 | because its integrity has been compromised or it does not meet the 18 | authorization criteria, IPE will deny its execution. Additionally, IPE 19 | generates audit logs which may be utilized to detect and analyze failures 20 | resulting from policy violation. 21 | 22 | Tampering threat scenarios include modification or replacement of 23 | executable code by a range of actors including: 24 | 25 | - Actors with physical access to the hardware 26 | - Actors with local network access to the system 27 | - Actors with access to the deployment system 28 | - Compromised internal systems under external control 29 | - Malicious end users of the system 30 | - Compromised end users of the system 31 | - Remote (external) compromise of the system 32 | 33 | IPE does not mitigate threats arising from malicious but authorized 34 | developers (with access to a signing certificate), or compromised 35 | developer tools used by them (i.e. return-oriented programming attacks). 36 | Additionally, IPE draws hard security boundary between userspace and 37 | kernelspace. As a result, IPE does not provide any protections against a 38 | kernel level exploit, and a kernel-level exploit can disable or tamper 39 | with IPE's protections. 40 | 41 | The root of trust for all of IPE's verifications is the 42 | `SYSTEM_TRUSTED_KEYRING` of the Linux kernel, which is a set of keys that 43 | are provisioned at kernel build-time. 44 | -------------------------------------------------------------------------------- /docs/usage/deployment.md: -------------------------------------------------------------------------------- 1 | # Deploying Policies 2 | 3 | Policies can be deployed from userspace through securityfs. These policies are signed through the PKCS#7 message format to enforce some level of authorization of the policies (prohibiting an attacker from gaining unconstrained root, and deploying an "allow all" policy). These policies must be signed by a certificate that chains to the `SYSTEM_TRUSTED_KEYRING`. With openssl, the policy can be signed by: 4 | 5 | ``` 6 | openssl smime -sign \ 7 | -in "$MY_POLICY" \ 8 | -signer "$MY_CERTIFICATE" \ 9 | -inkey "$MY_PRIVATE_KEY" \ 10 | -noattr \ 11 | -nodetach \ 12 | -nosmimecap \ 13 | -outform der \ 14 | -out "$MY_POLICY.p7b" 15 | ``` 16 | 17 | Deploying the policies is done through securityfs, through the `new_policy` node. To deploy a policy, simply cat the file into the securityfs node: 18 | 19 | ``` 20 | cat "$MY_POLICY.p7b" > /sys/kernel/security/ipe/new_policy 21 | ``` 22 | 23 | Upon success, this will create one subdirectory under `/sys/kernel/security/ipe/policies/`. The subdirectory will be the `policy_name` field of the policy deployed, so for the example above, the directory will be `/sys/kernel/security/ipe/policies/Ex_Policy`. Within this directory, there will be seven files: `pkcs7`, `policy`, `name`, `version`, `active`, `update`, and `delete`. 24 | 25 | The `pkcs7` file is read-only. Reading it returns the raw PKCS#7 data that was provided to the kernel, representing the policy. If the policy being read is the boot policy, this will return `ENOENT`, as it is not signed. 26 | 27 | The `policy` file is read only. Reading it returns the PKCS#7 inner content of the policy, which will be the plain text policy. 28 | 29 | The `active` file is used to set a policy as the currently active policy. This file is rw, and accepts a value of `"1"` to set the policy as active. Since only a single policy can be active at one time, all other policies will be marked inactive. The policy being marked active must have a policy version greater or equal to the currently-running version. 30 | 31 | The `update` file is used to update a policy that is already present in the kernel. This file is write-only and accepts a PKCS#7 signed policy. Two checks will always be performed on this policy: First, the `policy_names` must match with the updated version and the existing version. Second the updated policy must have a policy version greater than or equal to the currently-running version. This is to prevent rollback attacks. 32 | 33 | The `delete` file is used to remove a policy that is no longer needed. This file is write-only and accepts a value of `"1"` to delete the policy. On deletion, the securityfs node representing the policy will be removed. However, delete the current active policy is not allowed and will return an operation not permitted error. 34 | 35 | Similarly, writing to both `update` and `new_policy` could result in bad message(policy syntax error) or file exists error. The latter error happens when trying to deploy a policy with a `policy_name` while the kernel already has a deployed policy with the same `policy_name`. 36 | 37 | Deploying a policy will *not* cause IPE to start enforcing the policy. IPE will only enforce the policy marked active. Note that only one policy can be active at a time. 38 | 39 | Once deployment is successful, the policy can be activated, by writing file `/sys/kernel/security/ipe/policies/$policy_name/active`. For example, the `Ex_Policy` can be activated by: 40 | 41 | ``` 42 | echo 1 > "/sys/kernel/security/ipe/policies/Ex_Policy/active" 43 | ``` 44 | 45 | From above point on, `Ex_Policy` is now the enforced policy on the system. 46 | 47 | IPE also provides a way to delete policies. This can be done via the `delete` securityfs node, `/sys/kernel/security/ipe/policies/$policy_name/delete`. Writing `1` to that file deletes the policy: 48 | 49 | ``` 50 | echo 1 > "/sys/kernel/security/ipe/policies/$policy_name/delete" 51 | ``` 52 | 53 | There is only one requirement to delete a policy: the policy being deleted must be inactive. 54 | 55 | **NOTE:** 56 | 57 | If a traditional MAC system is enabled (SELinux, apparmor, smack), all writes to ipe's securityfs nodes require `CAP_MAC_ADMIN`. 58 | -------------------------------------------------------------------------------- /docs/usage/events.md: -------------------------------------------------------------------------------- 1 | # Audit Events 2 | 3 | ## 1420 AUDIT_IPE_ACCESS 4 | 5 | Event Examples: 6 | 7 | ``` 8 | type=1420 audit(1653364370.067:61): ipe_op=EXECUTE ipe_hook=MMAP enforcing=1 pid=2241 comm="ld-linux.so" path="/deny/lib/libc.so.6" dev="sda2" ino=14549020 rule="DEFAULT action=DENY" 9 | type=1300 audit(1653364370.067:61): SYSCALL arch=c000003e syscall=9 success=no exit=-13 a0=7f1105a28000 a1=195000 a2=5 a3=812 items=0 ppid=2219 pid=2241 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="ld-linux.so" exe="/tmp/ipe-test/lib/ld-linux.so" subj=unconfined key=(null) 10 | type=1327 audit(1653364370.067:61): 707974686F6E3300746573742F6D61696E2E7079002D6E00 11 | 12 | type=1420 audit(1653364735.161:64): ipe_op=EXECUTE ipe_hook=MMAP enforcing=1 pid=2472 comm="mmap_test" path=? dev=? ino=? rule="DEFAULT action=DENY" 13 | type=1300 audit(1653364735.161:64): SYSCALL arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=1000 a2=4 a3=21 items=0 ppid=2219 pid=2472 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="mmap_test" exe="/root/overlake_test/upstream_test/vol_fsverity/bin/mmap_test" subj=unconfined key=(null) 14 | type=1327 audit(1653364735.161:64): 707974686F6E3300746573742F6D61696E2E7079002D6E00 15 | ``` 16 | 17 | This event indicates that IPE made an access control decision; the IPE specific record (1420) is always emitted in conjunction with a `AUDITSYSCALL` record. 18 | 19 | Determining whether IPE is in permissive or enforced mode can be derived from `success` property and exit code of the `AUDITSYSCALL` record. 20 | 21 | Field descriptions: 22 | 23 | | Field | Value Type | Optional? | Description of Value | 24 | |------------|------------|-----------|---------------------------------------------------------------------------------| 25 | | ipe_op | string | No | The IPE operation name associated with the log | 26 | | ipe_hook | string | No | The name of the LSM hook that triggered the IPE event | 27 | | enforcing | integer | No | The current IPE enforcing state 1 is in enforcing mode, 0 is in permissive mode | 28 | | pid | integer | No | The pid of the process that triggered the IPE event. | 29 | | comm | string | No | The command line program name of the process that triggered the IPE event | 30 | | path | string | Yes | The absolute path to the evaluated file | 31 | | ino | integer | Yes | The inode number of the evaluated file | 32 | | dev | string | Yes | The device name of the evaluated file, e.g. vda | 33 | | rule | string | No | The matched policy rule | 34 | 35 | ## 1421 AUDIT_IPE_CONFIG_CHANGE 36 | 37 | Event Example: 38 | 39 | ``` 40 | type=1421 audit(1653425583.136:54): old_active_pol_name="Allow_All" old_active_pol_version=0.0.0 old_policy_digest=sha256:E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 new_active_pol_name="boot_verified" new_active_pol_version=0.0.0 new_policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F26765076DD8EED7B8F4DB auid=4294967295 ses=4294967295 lsm=ipe res=1 41 | type=1300 audit(1653425583.136:54): SYSCALL arch=c000003e syscall=1 success=yes exit=2 a0=3 a1=5596fcae1fb0 a2=2 a3=2 items=0 ppid=184 pid=229 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="python3" exe="/usr/bin/python3.10" key=(null) 42 | type=1327 audit(1653425583.136:54): PROCTITLE proctitle=707974686F6E3300746573742F6D61696E2E7079002D66002E2 43 | ``` 44 | 45 | This event indicates that IPE switched the active policy from one to another along with the version and the hash digest of the two policies. 46 | Note IPE can only have one policy active at a time, all access decision evaluation is based on the current active policy. 47 | The normal procedure to deploy a new policy is loading the policy to deploy into the kernel first, then switch the active policy to it. 48 | 49 | This record will always be emitted in conjunction with a `AUDITSYSCALL` record for the `write` syscall. 50 | 51 | Field descriptions: 52 | 53 | | Field | Value Type | Optional? | Description of Value | 54 | |------------------------|------------|-----------|---------------------------------------------------| 55 | | old_active_pol_name | string | No | The name of previous active policy | 56 | | old_active_pol_version | string | No | The version of previous active policy | 57 | | old_policy_digest | string | No | The hash of previous active policy | 58 | | new_active_pol_name | string | No | The name of current active policy | 59 | | new_active_pol_version | string | No | The version of current active policy | 60 | | new_policy_digest | string | No | The hash of current active policy | 61 | | auid | integer | No | The login user ID | 62 | | ses | integer | No | The login session ID | 63 | | lsm | string | No | The LSM name associated with the event | 64 | | res | integer | No | The result of the audited operation(success/fail) | 65 | 66 | ## 1422 AUDIT_IPE_POLICY_LOAD 67 | 68 | Event Example: 69 | 70 | ``` 71 | type=1422 audit(1653425529.927:53): policy_name="boot_verified" policy_version=0.0.0 policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F26765076DD8EED7B8F4DB auid=4294967295 ses=4294967295 lsm=ipe res=1 72 | type=1300 audit(1653425529.927:53): arch=c000003e syscall=1 success=yes exit=2567 a0=3 a1=5596fcae1fb0 a2=a07 a3=2 items=0 ppid=184 pid=229 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="python3" exe="/usr/bin/python3.10" key=(null) 73 | type=1327 audit(1653425529.927:53): PROCTITLE proctitle=707974686F6E3300746573742F6D61696E2E7079002D66002E2E 74 | ``` 75 | 76 | This record indicates a new policy has been loaded into the kernel with the policy name, policy version and policy hash. 77 | 78 | This record will always be emitted in conjunction with a `AUDITSYSCALL` record for the `write` syscall. 79 | 80 | Field descriptions: 81 | 82 | | Field | Value Type | Optional? | Description of Value | 83 | |----------------|------------|-----------|---------------------------------------------------| 84 | | policy_name | string | No | The policy_name | 85 | | policy_version | string | No | The policy_version | 86 | | policy_digest | string | No | The policy hash | 87 | | auid | integer | No | The login user ID | 88 | | ses | integer | No | The login session ID | 89 | | lsm | string | No | The LSM name associated with the event | 90 | | res | integer | No | The result of the audited operation(success/fail) | 91 | 92 | ## 1404 AUDIT_MAC_STATUS 93 | 94 | Event Examples: 95 | 96 | ``` 97 | type=1404 audit(1653425689.008:55): enforcing=0 old_enforcing=1 auid=4294967295 ses=4294967295 enabled=1 old-enabled=1 lsm=ipe res=1 98 | type=1300 audit(1653425689.008:55): arch=c000003e syscall=1 success=yes exit=2 a0=1 a1=55c1065e5c60 a2=2 a3=0 items=0 ppid=405 pid=441 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=) 99 | type=1327 audit(1653425689.008:55): proctitle="-bash" 100 | 101 | type=1404 audit(1653425689.008:55): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295 enabled=1 old-enabled=1 lsm=ipe res=1 102 | type=1300 audit(1653425689.008:55): arch=c000003e syscall=1 success=yes exit=2 a0=1 a1=55c1065e5c60 a2=2 a3=0 items=0 ppid=405 pid=441 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=) 103 | type=1327 audit(1653425689.008:55): proctitle="-bash" 104 | ``` 105 | 106 | This record will always be emitted in conjunction with a `AUDITSYSCALL` record for the `write` syscall. 107 | 108 | Field descriptions: 109 | 110 | | Field | Value Type | Optional? | Description of Value | 111 | |---------------|------------|-----------|-------------------------------------------------------------------------------------------------| 112 | | enforcing | integer | No | The enforcing state IPE is being switched to, 1 is in enforcing mode, 0 is in permissive mode | 113 | | old_enforcing | integer | No | The enforcing state IPE is being switched from, 1 is in enforcing mode, 0 is in permissive mode | 114 | | auid | integer | No | The login user ID | 115 | | ses | integer | No | The login session ID | 116 | | enabled | integer | No | The new TTY audit enabled setting | 117 | | old-enabled | integer | No | The old TTY audit enabled setting | 118 | | lsm | string | No | The LSM name associated with the event | 119 | | res | integer | No | The result of the audited operation (success/fail) | 120 | 121 | ## Success Auditing 122 | 123 | IPE supports success auditing. When enabled, all events that pass IPE policy and are not blocked will emit an audit event. This is disabled by default, and can be enabled via the kernel command line `ipe.success_audit=(0|1)` or `/sys/kernel/security/ipe/success_audit` securityfs file. 124 | 125 | This is *very* noisy, as IPE will check every userspace binary on the system, but is useful for debugging policies. 126 | 127 | **NOTE:** 128 | 129 | If a traditional MAC system is enabled (SELinux, apparmor, smack, etcetera), all writes to ipe's securityfs nodes require `CAP_MAC_ADMIN`. 130 | -------------------------------------------------------------------------------- /docs/usage/examples.md: -------------------------------------------------------------------------------- 1 | # Policy Examples 2 | 3 | ## Allow all 4 | 5 | ``` 6 | policy_name=Allow_All policy_version=0.0.0 7 | DEFAULT action=ALLOW 8 | ``` 9 | 10 | ## Allow only initramfs 11 | 12 | ``` 13 | policy_name=Allow_All_Initramfs policy_version=0.0.0 14 | DEFAULT action=DENY 15 | 16 | op=EXECUTE boot_verified=TRUE action=ALLOW 17 | ``` 18 | 19 | ## Allow any signed dm-verity volume and the initramfs 20 | 21 | ``` 22 | policy_name=AllowSignedAndInitramfs policy_version=0.0.0 23 | DEFAULT action=DENY 24 | 25 | op=EXECUTE boot_verified=TRUE action=ALLOW 26 | op=EXECUTE dmverity_signature=TRUE action=ALLOW 27 | ``` 28 | 29 | ## Prohibit execution from a specific dm-verity volume 30 | 31 | ``` 32 | policy_name=AllowSignedAndInitramfs policy_version=0.0.0 33 | DEFAULT action=DENY 34 | 35 | op=EXECUTE dmverity_roothash=sha256:cd2c5bae7c6c579edaae4353049d58eb5f2e8be0244bf05345bc8e5ed257baff action=DENY 36 | 37 | op=EXECUTE boot_verified=TRUE action=ALLOW 38 | op=EXECUTE dmverity_signature=TRUE action=ALLOW 39 | ``` 40 | 41 | ## Allow only a specific dm-verity volume 42 | 43 | ``` 44 | policy_name=AllowSignedAndInitramfs policy_version=0.0.0 45 | DEFAULT action=DENY 46 | 47 | op=EXECUTE dmverity_roothash=sha256:401fcec5944823ae12f62726e8184407a5fa9599783f030dec146938 action=ALLOW 48 | ``` 49 | 50 | ## Allow any signed fs-verity file 51 | 52 | ``` 53 | policy_name=AllowSignedFSVerity policy_version=0.0.0 54 | DEFAULT action=DENY 55 | 56 | op=EXECUTE fsverity_signature=TRUE action=ALLOW 57 | ``` 58 | 59 | ## Prohibit execution of a specific fs-verity file 60 | 61 | ``` 62 | policy_name=ProhibitSpecificFSVF policy_version=0.0.0 63 | DEFAULT action=DENY 64 | 65 | op=EXECUTE fsverity_digest=sha256:fd88f2b8824e197f850bf4c5109bea5cf0ee38104f710843bb72da796ba5af9e action=DENY 66 | op=EXECUTE boot_verified=TRUE action=ALLOW 67 | op=EXECUTE dmverity_signature=TRUE action=ALLOW 68 | ``` 69 | -------------------------------------------------------------------------------- /docs/usage/index.md: -------------------------------------------------------------------------------- 1 | # Policy 2 | 3 | IPE policy is a plain-text policy composed of multiple statements over several lines. There is one required line, at the top of the policy, indicating the policy name, and the policy version, for instance: 4 | 5 | `policy_name=Ex_Policy policy_version=0.0.0` 6 | 7 | The policy name is a unique key identifying this policy in a human readable name. This is used to create nodes under securityfs as well as uniquely identify policies to deploy new policies vs update existing policies. 8 | 9 | The policy version indicates the current version of the policy (NOT the policy syntax version). This is used to prevent rollback of policy to potentially insecure previous versions of the policy. 10 | 11 | The next portion of IPE policy are rules. Rules are formed by key=value pairs, known as properties. IPE rules require two properties: `action`, which determines what IPE does when it encounters a match against the rule, and `op`, which determines when the rule should be evaluated. The ordering is significant, a rule must start with `op`, and end with `action`. Thus, a minimal rule is: 12 | 13 | `op=EXECUTE action=ALLOW` 14 | 15 | This example will allow any execution. Additional properties are used to assess immutable security properties about the files being evaluated. These properties are intended to be descriptions of systems within the kernel that can provide a measure of integrity verification, such that IPE can determine the trust of the resource based on the value of the property. 16 | 17 | Rules are evaluated top-to-bottom. As a result, any revocation rules, or denies should be placed early in the file to ensure that these rules are evaluated before a rule with `action=ALLOW`. 18 | 19 | IPE policy supports comments. The character '#' will function as a comment, ignoring all characters to the right of '#' until the newline. 20 | 21 | The default behavior of IPE evaluations can also be expressed in policy, through the `DEFAULT` statement. This can be done at a global level, or a per-operation level: 22 | ``` 23 | #Global 24 | DEFAULT action=ALLOW 25 | 26 | #Operation Specific 27 | DEFAULT op=EXECUTE action=ALLOW 28 | ``` 29 | 30 | A default must be set for all known operations in IPE. If you want to preserve older policies being compatible with newer kernels that can introduce new operations, set a global default of `ALLOW`, then override the defaults on a per-operation basis (as above). 31 | 32 | With configurable policy-based LSMs, there's several issues with enforcing the configurable policies at startup, around reading and parsing the policy: 33 | 34 | 1. The kernel *should* not read files from userspace, so directly reading the policy file is prohibited. 35 | 2. The kernel command line has a character limit, and one kernel module should not reserve the entire character limit for its own configuration. 36 | 3. There are various boot loaders in the kernel ecosystem, so handing off a memory block would be costly to maintain. 37 | 38 | As a result, IPE has addressed this problem through a concept of a "boot policy". A boot policy is a minimal policy which is compiled into the kernel. This policy is intended to get the system to a state where userspace is set up and ready to receive commands, at which point a more complex policy can be deployed via securityfs. The boot policy can be specified via `SECURITY_IPE_BOOT_POLICY` config option, which accepts a path to a plain-text version of the IPE policy to apply. This policy will be compiled into the kernel. If not specified, IPE will be disabled until a policy is deployed and activated through securityfs. 39 | 40 | # Modes 41 | 42 | IPE supports two modes of operation: permissive (similar to SELinux's permissive mode) and enforced. In permissive mode, all events are checked and policy violations are logged, but the policy is not really enforced. This allows users to test policies before enforcing them. 43 | 44 | The default mode is enforce, and can be changed via the kernel command line parameter `ipe.enforce=(0|1)`, or the securityfs node `/sys/kernel/security/ipe/enforce`. 45 | 46 | **NOTE:** 47 | 48 | If a traditional MAC system is enabled (SELinux, apparmor, smack, etcetera), all writes to ipe's securityfs nodes require `CAP_MAC_ADMIN`. 49 | -------------------------------------------------------------------------------- /docs/usage/properties.md: -------------------------------------------------------------------------------- 1 | # IPE Properties 2 | 3 | IPE properties are `key=value` pairs expressed in IPE 4 | policy. Two properties are built into the policy parser: 'op' and 'action'. 5 | The other properties are used to restrict immutable security properties 6 | about the files being evaluated. Currently those properties are: 7 | `boot_verified`, `dmverity_signature`, `dmverity_roothash`, 8 | `fsverity_signature`, `fsverity_digest`. A description of all 9 | properties supported by IPE are listed below: 10 | 11 | ## op 12 | 13 | Indicates the operation for a rule to apply to. Must be in every rule, 14 | as the first token. IPE supports the following operations: 15 | 16 | - **EXECUTE** 17 | - Pertains to any file attempting to be executed, or loaded as an 18 | executable. 19 | 20 | - **FIRMWARE**: 21 | - Pertains to firmware being loaded via the firmware_class interface. 22 | This covers both the preallocated buffer and the firmware file 23 | itself. 24 | 25 | - **KMODULE**: 26 | - Pertains to loading kernel modules via `modprobe` or `insmod`. 27 | 28 | - **KEXEC_IMAGE**: 29 | - Pertains to kernel images loading via `kexec`. 30 | 31 | - **KEXEC_INITRAMFS** 32 | - Pertains to initrd images loading via `kexec --initrd`. 33 | 34 | - **POLICY**: 35 | - Controls loading policies via reading a kernel-space initiated read. 36 | An example of such is loading IMA policies by writing the path 37 | to the policy file to `$securityfs/ima/policy`. 38 | 39 | - **X509_CERT**: 40 | - Controls loading IMA certificates through the Kconfigs, 41 | `CONFIG_IMA_X509_PATH` and `CONFIG_EVM_X509_PATH`. 42 | 43 | ## action 44 | 45 | Determines what IPE should do when a rule matches. Must be in every 46 | rule, as the final clause. Can be one of: 47 | 48 | - **ALLOW**: 49 | - If the rule matches, explicitly allow access to the resource to proceed 50 | without executing any more rules. 51 | 52 | - **DENY**: 53 | - If the rule matches, explicitly prohibit access to the resource to 54 | proceed without executing any more rules. 55 | 56 | ## boot_verified 57 | 58 | This property can be utilized for authorization of files from initramfs. 59 | The format of this property is: 60 | 61 | boot_verified=(TRUE|FALSE) 62 | 63 | **WARNING:** 64 | 65 | This property will trust files from initramfs(rootfs). It should 66 | only be used during the early booting stage. Before mounting the real 67 | rootfs on top of the initramfs, initramfs script will recursively 68 | remove all files and directories on the initramfs. This is typically 69 | implemented by using switch_root(8). Therefore the initramfs will be empty and not accessible after the real 70 | rootfs takes over. It is advised to switch to a different policy 71 | that doesn't rely on the property after this point. 72 | This ensures that the trust policies remain relevant and effective 73 | throughout the system's operation. 74 | 75 | ## dmverity_roothash 76 | 77 | This property can be utilized for authorization or revocation of 78 | specific dm-verity volumes, identified via its root hash. It has a 79 | dependency on the DM_VERITY module. This property is controlled by 80 | the `IPE_PROP_DM_VERITY` config option, it will be automatically 81 | selected when `IPE_SECURITY`, `DM_VERITY` and 82 | `DM_VERITY_VERIFY_ROOTHASH_SIG` are all enabled. 83 | The format of this property is: 84 | 85 | dmverity_roothash=DigestName:HexadecimalString 86 | 87 | The supported DigestNames for dmverity_roothash are: 88 | 89 | - blake2b-512 90 | - blake2s-256 91 | - sha1 92 | - sha256 93 | - sha384 94 | - sha512 95 | - sha3-224 96 | - sha3-256 97 | - sha3-384 98 | - sha3-512 99 | - md4 100 | - md5 101 | - sm3 102 | - rmd160 103 | 104 | ## dmverity_signature 105 | 106 | This property can be utilized for authorization of all dm-verity 107 | volumes that have a signed roothash that validated by a keyring 108 | specified by dm-verity's configuration, either the system trusted 109 | keyring, or the secondary keyring. It depends on 110 | `DM_VERITY_VERIFY_ROOTHASH_SIG` config option and is controlled by 111 | the `IPE_PROP_DM_VERITY` config option, it will be automatically 112 | selected when `IPE_SECURITY`, `DM_VERITY` and 113 | `DM_VERITY_VERIFY_ROOTHASH_SIG` are all enabled. 114 | The format of this property is: 115 | 116 | dmverity_signature=(TRUE|FALSE) 117 | 118 | ## fsverity_digest 119 | 120 | This property can be utilized for authorization or revocation of 121 | specific fsverity enabled file, identified via its fsverity digest. 122 | It depends on `FS_VERITY` config option and is controlled by 123 | `CONFIG_IPE_PROP_FS_VERITY`. The format of this property is: 124 | 125 | fsverity_digest=DigestName:HexadecimalString 126 | 127 | The supported DigestNames for fsverity_roothash are: 128 | 129 | - sha256 130 | - sha512 131 | 132 | ## fsverity_signature 133 | 134 | This property is used to authorize all fs-verity enabled files that have 135 | been verified by fs-verity's built-in signature mechanism. The signature 136 | verification relies on a key stored within the ".fs-verity" keyring. It 137 | depends on `CONFIG_FS_VERITY_BUILTIN_SIGNATURES` and it is controlled by 138 | the Kconfig `CONFIG_IPE_PROP_FS_VERITY`. The format of this 139 | property is: 140 | 141 | fsverity_signature=(TRUE|FALSE) 142 | -------------------------------------------------------------------------------- /mkdocs.yml: -------------------------------------------------------------------------------- 1 | site_name: Integrity Policy Enforcement 2 | repo_url: https://github.com/microsoft/ipe 3 | copyright: Copyright (c) Microsoft. All rights reserved. 4 | site_description: "Integrity Policy Enforcement (IPE) Documentation" 5 | site_url: "https://microsoft.github.io/ipe" 6 | theme: 7 | name: 'mkdocs' 8 | 9 | nav: 10 | - Home: "index.md" 11 | - Usage: 12 | - Overview: "usage/index.md" 13 | - Properties: "usage/properties.md" 14 | - Deploying Policies: "usage/deployment.md" 15 | - Example Policies: "usage/examples.md" 16 | - Audit Events: "usage/events.md" 17 | - Technical: 18 | - Threat Model: "technical/threat-model.md" 19 | - Technical Diagrams: "technical/diagrams.md" 20 | - Other: 21 | - FAQ: "faq.md" 22 | - Presentations: "presentations.md" 23 | - Attribution: "attribution.md" 24 | - License: "license.md" 25 | --------------------------------------------------------------------------------