-
Notifications
You must be signed in to change notification settings - Fork 9
Expand file tree
/
Copy pathauditing.xml
More file actions
274 lines (273 loc) · 12.8 KB
/
auditing.xml
File metadata and controls
274 lines (273 loc) · 12.8 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
<!DOCTYPE html>
<html lang="en" prefix="og: http://ogp.me/ns#">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>BCHS//openradtool: auditing RBAC</title>
<script src="https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js?lang=c&lang=sql"></script>
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Alegreya+Sans:400,400italic,500,700" />
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" />
<link rel="stylesheet" href="highlight.css" />
<link rel="stylesheet" href="kwebapp.css" />
<link rel="stylesheet" href="audit.css" />
<link rel="shortcut icon" type="image/png" href="/favicon-196x196.png" />
<link rel="shortcut icon" sizes="196x196" href="/favicon-196x196.png" />
<link rel="apple-touch-icon" href="/favicon-196x196.png" />
<meta property="og:title" content="BCHS and openradtool: auditing RBAC" />
<meta property="og:image" content="https://learnbchs.org/logo-blue.png" />
<meta property="og:url" content="https://learnbchs.org/auditing.html" />
<meta property="og:type" content="website" />
<meta property="og:description" content="BCHS tools for auditing application role-based access control (RBAC)." />
<meta name="description" content="BCHS tools for auditing application role-based access control (RBAC)." />
</head>
<body>
<section itemscope="itemscope" itemtype="http://schema.org/WebPage">
<nav class="subnav">
openradtool series:
<a href="kwebapp.html">introduction</a>,
<a href="rbac.html">RBAC</a>,
<a href="auditing.html">role audits</a>,
<a href="translate.html">translation</a>,
<a href="typescript.html">TypeScript</a>
</nav>
<header>
<img itemprop="image" src="logo-blue.png" alt="BCHS Logo" />
<h1>
<a href="index.html" itemprop="name">BCHS</a>
</h1>
<nav>
<a href="tools.html"><span>tools</span></a>
<a href="easy.html"><span>example</span></a>
<a href="https://github.com/kristapsdz/bchs"><i class="fa fa-github"></i></a>
</nav>
</header>
<article>
<header>
<p class="tldr">
<strong>tl;dr</strong>
<a href="https://kristaps.bsd.lv/openradtool">openradtool</a> now features a tool for auditing
role-based access control enforced by <a href="https://man.openbsd.org">pledge(2)</a>.
This piece is an abridged version of my <a href="https://kristaps.bsd.lv/absdcon2018">AsiaBSDCon
2018</a> talk.
</p>
<h2 class="smaller">
<a href="index.html">BCHS</a>: role audits
</h2>
</header>
<section class="intro">
<p>
This article is about web application security.
</p>
<p>
It can be applied to any application, really, but fits most with those having the concept of a
single data source servicing multiple operating <em>roles</em>.
For example, most web applications have at least the concept of administrators, registered
users, and unregistered users—all of whom at some point act to invoke the application and
touch the database.
Regular applications usually don't have this ecosystem, hence the focus on web applications.
</p>
<p>
And of course, it relates to the C programming language, <a
href="https://www.openbsd.org">OpenBSD</a>, and <a href="https://sqlite.org">SQLite</a>
(collectively, <a href="index.html">BCHS</a>).
Conceptually, none of the tools I mention are limited to these systems, but they're the systems
I use.
Feel free to submit portability patches—and I'd love to have <a
href="https://kristaps.bsd.lv/openradtool">openradtool</a> output into other languages.
</p>
<p>
To date, I've used <a href="https://kristaps.bsd.lv/ksql">ksql</a>+<a
href="https://kristaps.bsd.lv/kcgi">kcgi</a> to protect my applications from the network,
then my database from my application.
I talk more about database protection in my <a href="ksql.html">split-process SQLite</a>
article—the network protection has similar principles but no fancy blog posting.
</p>
<figure>
<img src="auditing-fig2.svg" />
</figure>
<p>
<a href="https://man.openbsd.org/pledge.2">pledge(2)</a> enables these by constraining available
resources:
</p>
<ol>
<li>
Limit the network parsing process so that it can only pass sanitise input over IPC to
the parent (<q class="literal">stdio</q> or <q class="literal">unix</q>…).
</li>
<li>
Limit the database process to only have access to the database (<q
class="literal">rpath</q>, <q class="literal">cpath</q>, …) and manage
requests for access over IPC.
</li>
<li>
Lastly, limit the application process to IPC (<q class="literal">stdio</q>) only,
keeping its connection to the parse sequence and database.
</li>
</ol>
<p>
This only goes so far as to protect me at the broadest application level: I know that I'm safe
from bad formats, and that my data is safe from, well, my programming errors. What it doesn't
provide is safety within the <em>logical</em> environment of my application. For example, it
doesn't guarantee that an unregistered user invoking the application can mess with administrator
tables.
</p>
<p>
Said another way, it doesn't protect the application from sloppy business logic—just
sloppy programming.
Unfortunately, I do both.
</p>
<p>
For this, I need more powerful semantics like those of <a
href="https://en.wikipedia.org/wiki/Role-based_access_control">role-based access
control</a> (RBAC).
I bring in <a href="https://kristaps.bsd.lv/openradtool">openradtool</a> for this facility, which,
beyond hugely simplifying my data layer, features role assignment and provisioning for the data
layer of an application.
(I discuss this at length in my <a href="rbac.html">RBAC</a> article.)
</p>
<figure>
<img src="auditing-fig1.svg" />
</figure>
<p>
As of version 0.4.6, <a href="https://kristaps.bsd.lv/openradtool">openradtool</a>
pushed its RBAC implementation directly into <a href="https://kristaps.bsd.lv/ksql">ksql</a>,
taking advantage of the split-process model to ensure that role assignment occurred outside the
process space of our vulnerable application.
<strong>Note: openradtool uses the most current versions of ksql+kcgi: they are all developed in tandem.</strong>
This gives our application a great boon: <strong>guarantees</strong> about roles.
</p>
<figure>
<img src="auditing-fig3.svg" />
</figure>
<p>
We might have the strongest protection, but an important question remains: in any sufficiently
large application, how can we know which roles can access which data?
</p>
<h3>
introducing roles
</h3>
<p>
Enforcing role-based access control in <a href="https://kristaps.bsd.lv/openradtool">openradtool</a> is
easy even for existing applications.
Starting with an existing <a
href="https://kristaps.bsd.lv/openradtool/ort.5.html">ort(5)</a>
configuration.
This configuration declares the <code>session</code> and <code>user</code> types: a log-in
session and a user entity (<q>principle</q>) who is logged in.
</p>
<p>
The session knows about its logged-in user, last modification time (for time-outs), a unique
token to prevent session guessing, and its identifier.
Sessions may be deleted, created, and queried.
The user has an e-mail address, name, hashed password, and identifier.
It may also be created, modified, and queried—but not deleted.
</p>
<p>
Naturally, we document our objects, fields, and operations!
</p>
<article data-sblg-article="1" data-sblg-permlink="0"></article>
<p>
We needn't explore all of the generated API, but it suffices to see that this generates
structures for all of the types and functions for all operations.
All documentation is preserved.
See <a href="https://kristaps.bsd.lv/openradtool/ort-c-header.1.html">ort-c-header(1)</a>
for the nitty-gritty details.
</p>
<article data-sblg-article="1" data-sblg-permlink="0"></article>
<p>
Let's augment our simple example with two user roles: users and administrators.
We'll let users… use the system.
Administrators will have the ability to add users and nothing more.
There's also the concept of the default role, which is in effect when the system starts, before
we've actually figured out the operator principle.
</p>
<article data-sblg-article="1" data-sblg-permlink="0"></article>
<p>
It's pretty easy to wrap our minds around this.
But what happens when our data model grows to dozens of interrelated tables?
It's awfully hard to see whether any given role might have indirect access to a table.
</p>
<p>
The canonical example is the controlling administrator.
Lets say we have an administrator type who's referenced by a company table as the creator of the
row.
Our users are attached to a company, so each time a user object is written, the company is
included in that object.
And thus—the administrator.
But we don't want users to know about administrators!
<a href="https://kristaps.bsd.lv/openradtool/ort.5.html">ort(5)</a> has a
<code>noexport</code> keyword to prevent certain roles from seeing certain information, but what
if we forget? How will we ever know?
</p>
<p>
Fortunately, there's a tool to make sure this doesn't happen.
</p>
<h3>
auditing roles
</h3>
<p>
Audits are a way for developers, managers, and, well, auditors to trace who has access to what.
The <a href="https://kristaps.bsd.lv/openradtool/ort-audit.1.html">ort-audit(1)</a> tool
creates these audits on the terminal, as JSON output with <a
href="https://kristaps.bsd.lv/openradtool/ort-audit-json.1.html">ort-audit-json(1)</a>,
and even GraphViz with <a
href="https://kristaps.bsd.lv/openradtool/ort-audit-gv.1.html">ort-audit-gv(1)</a>.
Let's take a look at our user (and yes, this is from an actual audit run, and real output from
the mentioned utilities embedded in this page)…
</p>
<article data-sblg-article="1" data-sblg-permlink="0"></article>
<p>
The audit begins with the role name and its documentation.
It then looks at each object and how it can be accessed by principles of that role.
For example, the <code>uid</code> of the user isn't exported, and access of that field comes
through its search function.
If an object can be indirectly accessed—such as a foreign key reference—all paths
from the referencee to referenced are noted.
</p>
<p>
Clicking on any field or function produces its documentation.
</p>
<p>
Below the field layout, we list all operations by category.
This is useful for a quick check on the <em>actions</em> allowed by the role.
</p>
<p>
We can get a quick sense by using the <a href="https://graphviz.org">GraphViz</a> output mode,
which simply shows all accessible and exportable fields per role.
For this, I've slightly expanded the above example by adding another table.
</p>
<article data-sblg-article="1" data-sblg-permlink="0"></article>
<p>
We'll look at the <q>default</q> role, this time.
Links between objects (the chain of <q>foreign keys</q> from the original query) are noted with
arrows—the dotted lines are interior links in multi-step foreign key references.
I also show the query functions themselves.
Non-exportable fields are greyed out, as are entirely non-exportable tables.
</p>
<figure>
<img src="auditing-fig8.svg" />
</figure>
<p>
That's it!
We can clearly see the linkage between exported entries.
</p>
<h3>
acknowledgements
</h3>
<p>
I'd like to thank CAPEM Solutions, Inc., for funding this development and agreeing that it bests
serves the community as open source.
I'd also like to thank <a href="https://asiabsdcon.org">AsiaBSDCon</a> for letting me
pontificate on these topics at <a href="https://2018.asiabsdcon.org">AsiaBSDCon 2018</a>.
</p>
</section>
</article>
<footer>
<div>
<a href="https://creativecommons.org/licenses/by/4.0/"><i class="fa fa-creative-commons"></i></a>
<a rel="author" href="https://github.com/kristapsdz">Kristaps Dzonsons</a>
</div>
</footer>
</section>
</body>
</html>