/usr/share/doc/xorg-docs/Xserver/secint.html is in xorg-docs 1:1.7-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
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 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 | <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Security Extension Server Design Draft</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1" /><meta name="description" content="This paper describes the implementation strategy used to implement various pieces of the SECURITY Extension." /><style xmlns="" type="text/css">/*
* Copyright (c) 2011 Gaetan Nadon
* Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
*/
/*
* Shared stylesheet for X.Org documentation translated to HTML format
* http://www.sagehill.net/docbookxsl/UsingCSS.html
* http://www.w3schools.com/css/default.asp
* https://addons.mozilla.org/en-US/firefox/addon/web-developer/developers
* https://addons.mozilla.org/en-US/firefox/addon/font-finder/
*/
/*
* The sans-serif fonts are considered more legible on a computer screen
* http://dry.sailingissues.com/linux-equivalents-verdana-arial.html
*
*/
body {
font-family: "Bitstream Vera Sans", "DejaVu Sans", Tahoma, Geneva, Arial, Sans-serif;
/* In support of using "em" font size unit, the w3c recommended method */
font-size: 100%;
}
/*
* Selection: all elements requiring mono spaced fonts.
*
* The family names attempt to match the proportionally spaced font
* family names such that the same font name is used for both.
* We'd like to use Bitstream, for example, in both proportionally and
* mono spaced font text.
*/
.command,
.errorcode,
.errorname,
.errortype,
.filename,
.funcsynopsis,
.function,
.parameter,
.programlisting,
.property,
.screen,
.structname,
.symbol,
.synopsis,
.type
{
font-family: "Bitstream Vera Sans Mono", "DejaVu Sans Mono", Courier, "Liberation Mono", Monospace;
}
/*
* Books have a title page, a preface, some chapters and appendices,
* a glossary, an index and a bibliography, in that order.
*
* An Article has no preface and no chapters. It has sections, appendices,
* a glossary, an index and a bibliography.
*/
/*
* Selection: book main title and subtitle
*/
div.book>div.titlepage h1.title,
div.book>div.titlepage h2.subtitle {
text-align: center;
}
/*
* Selection: article main title and subtitle
*/
div.article>div.titlepage h2.title,
div.article>div.titlepage h3.subtitle,
div.article>div.sect1>div.titlepage h2.title,
div.article>div.section>div.titlepage h2.title {
text-align: center;
}
/*
* Selection: various types of authors and collaborators, individuals or corporate
*
* These authors are not always contained inside an authorgroup.
* They can be contained inside a lot of different parent types where they might
* not be centered.
* Reducing the margin at the bottom makes a visual separation between authors
* We specify here the ones on the title page, others may be added based on merit.
*/
div.titlepage .authorgroup,
div.titlepage .author,
div.titlepage .collab,
div.titlepage .corpauthor,
div.titlepage .corpcredit,
div.titlepage .editor,
div.titlepage .othercredit {
text-align: center;
margin-bottom: 0.25em;
}
/*
* Selection: the affiliation of various types of authors and collaborators,
* individuals or corporate.
*/
div.titlepage .affiliation {
text-align: center;
}
/*
* Selection: product release information (X Version 11, Release 7)
*
* The releaseinfo element can be contained inside a lot of different parent
* types where it might not be centered.
* We specify here the one on the title page, others may be added based on merit.
*/
div.titlepage p.releaseinfo {
font-weight: bold;
text-align: center;
}
/*
* Selection: publishing date
*/
div.titlepage .pubdate {
text-align: center;
}
/*
* The legal notices are displayed in smaller sized fonts
* Justification is only supported in IE and therefore not requested.
*
*/
.legalnotice {
font-size: small;
font-style: italic;
}
/*
* Selection: book or article main ToC title
* A paragraph is generated for the title rather than a level 2 heading.
* We do not want to select chapters sub table of contents, only the main one
*/
div.book>div.toc>p,
div.article>div.toc>p {
font-size: 1.5em;
text-align: center;
}
/*
* Selection: major sections of a book or an article
*
* Unlike books, articles do not have a titlepage element for appendix.
* Using the selector "div.titlepage h2.title" would be too general.
*/
div.book>div.preface>div.titlepage h2.title,
div.book>div.chapter>div.titlepage h2.title,
div.article>div.sect1>div.titlepage h2.title,
div.article>div.section>div.titlepage h2.title,
div.book>div.appendix>div.titlepage h2.title,
div.article>div.appendix h2.title,
div.glossary>div.titlepage h2.title,
div.index>div.titlepage h2.title,
div.bibliography>div.titlepage h2.title {
/* Add a border top over the major parts, just like printed books */
/* The Gray color is already used for the ruler over the main ToC. */
border-top-style: solid;
border-top-width: 2px;
border-top-color: Gray;
/* Put some space between the border and the title */
padding-top: 0.2em;
text-align: center;
}
/*
* A Screen is a verbatim environment for displaying text that the user might
* see on a computer terminal. It is often used to display the results of a command.
*
* http://www.css3.info/preview/rounded-border/
*/
.screen {
background: #e0ffff;
border-width: 1px;
border-style: solid;
border-color: #B0C4DE;
border-radius: 1.0em;
/* Browser's vendor properties prior to CSS 3 */
-moz-border-radius: 1.0em;
-webkit-border-radius: 1.0em;
-khtml-border-radius: 1.0em;
margin-left: 1.0em;
margin-right: 1.0em;
padding: 0.5em;
}
/*
* Emphasis program listings with a light shade of gray similar to what
* DocBook XSL guide does: http://www.sagehill.net/docbookxsl/ProgramListings.html
* Found many C API docs on the web using like shades of gray.
*/
.programlisting {
background: #F4F4F4;
border-width: 1px;
border-style: solid;
border-color: Gray;
padding: 0.5em;
}
/*
* Emphasis functions synopsis using a darker shade of gray.
* Add a border such that it stands out more.
* Set the padding so the text does not touch the border.
*/
.funcsynopsis, .synopsis {
background: #e6e6fa;
border-width: 1px;
border-style: solid;
border-color: Gray;
clear: both;
margin: 0.5em;
padding: 0.25em;
}
/*
* Selection: paragraphs inside synopsis
*
* Removes the default browser margin, let the container set the padding.
* Paragraphs are not always used in synopsis
*/
.funcsynopsis p,
.synopsis p {
margin: 0;
padding: 0;
}
/*
* Selection: variable lists, informal tables and tables
*
* Note the parameter name "variablelist.as.table" in xorg-xhtml.xsl
* A table with rows and columns is constructed inside div.variablelist
*
* Set the left margin so it is indented to the right
* Display informal tables with single line borders
*/
table {
margin-left: 0.5em;
border-collapse: collapse;
}
/*
* Selection: paragraphs inside tables
*
* Removes the default browser margin, let the container set the padding.
* Paragraphs are not always used in tables
*/
td p {
margin: 0;
padding: 0;
}
/*
* Add some space between the left and right column.
* The vertical alignment helps the reader associate a term
* with a multi-line definition.
*/
td, th {
padding-left: 1.0em;
padding-right: 1.0em;
vertical-align: top;
}
.warning {
border: 1px solid red;
background: #FFFF66;
padding-left: 0.5em;
}
</style></head><body><div class="book"><div class="titlepage"><div><div><h1 class="title"><a id="secint"></a>Security Extension Server Design Draft</h1></div><div><h2 class="subtitle">X Consortium Standard</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">David</span> <span class="othername">P.</span> <span class="surname">Wiggins</span></h3><div class="affiliation"><span class="orgname">X Consortium<br /></span></div></div></div></div><div><p class="releaseinfo">X Version 11, Release 7.6</p></div><div><p class="releaseinfo">Version 3.0</p></div><div><p class="copyright">Copyright © 1996 X Consortium</p></div><div><div class="legalnotice"><a id="idp33461260"></a><p>
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
</p><p>
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
</p><p>
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.
</p><p>
Except as contained in this notice, the name of the X Consortium shall
not be used in advertising or otherwise to promote the sale, use or
other dealings in this Software without prior written authorization
from the X Consortium.
</p><p>X Window System is a trademark of The Open Group.</p></div></div><div><p class="pubdate">June 27, 2010</p></div><div><div class="abstract"><p>This paper describes the implementation strategy used to implement
various pieces of the SECURITY Extension.
</p></div></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="chapter"><a href="#Generate_Authorization_Request">1. Generate Authorization Request</a></span></dt><dt><span class="chapter"><a href="#Client_Connection">2. Client Connection</a></span></dt><dt><span class="chapter"><a href="#Client_disconnection">3. Client disconnection</a></span></dt><dt><span class="chapter"><a href="#Resource_ID_Security">4. Resource ID Security</a></span></dt><dt><span class="chapter"><a href="#Extension_Security">5. Extension Security</a></span></dt></dl></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a id="Generate_Authorization_Request"></a>Chapter 1. Generate Authorization Request</h1></div></div></div><p>
The major steps taken to execute this request are as follows.
</p><p>
Sanity check arguments. The interesting one is the group, which must be
checked by some other module(s), initially just the embedding extension.
Use a new callback for this. The callback functions will be passed a small
structure containing the group ID and a Boolean value which is initially
false. If any of the callbacks recognize the ID, they should set the boolean
to true. If after the callbacks have been called the boolean is false, return
an error, since nobody recognized it.
</p><p>
Use the existing Xkey library function XkeyGenerateAuthorization to generate
the new authorization.
</p><p>
Use the existing os layer function AddAuthorization to add the new
authorization to the server's internal database.
</p><p>
Use the existing os layer function AuthorizationToID to retrieve
the authorization ID that the os layer assigned to the new authorization.
</p><p>Change the os layer to use authorization IDs allocated from the
server's ID range via FakeClientID(0) instead of using a simple incrementing
integer. This lets us use the resource database to attach additional
information to an authorization without needing any changes to os
data structures.
</p><p>
Add the authorization ID as a server resource. The structure for an
authorization resource will contain the timeout, trust-level, and group
sent in the request, a reference count of how many clients are connected
with this authorization, a timer pointer, and time-remaining counter.
</p><p>
Return the authorization ID and generated auth data to the client.
</p></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a id="Client_Connection"></a>Chapter 2. Client Connection</h1></div></div></div><p>
The Security extension needs to be aware of new client connections
primarily so that it copy the trust-level of the authorization that was
used to the client structure. The trust-level is needed in the client
structure because it will be accessed frequently to make access control
decisions for the client. We will use the existing ClientStateCallback
to catch new client connections.
</p><p>
We also need to copy the authorization ID into the client structure. The
authorization ID is already stored in an os private hung from the client,
and we will add a new os function AuthorizationIDOfClient to retrieve it.
However, when a client disconnects, this os private is already gone before
ClientStateCallbacks are called. We need the authorization ID at client
disconnect time for reasons described below.
</p><p>
Now that we know what needs to be done and why, let's walk through the
sequnce of events.
</p><p>
When a new client connects, get the authorization ID with
AuthorizationIDOfClient, store it in the client, then pass that ID to
LookupIDByType to find the authorization. If we get a non-NULL pointer
back, this is a generated authorization, not one of the predefined ones in
the server's authority file. In this case, increment the authorization's
reference count. If the reference count is now 1, cancel the timer
for this authorization using the trivial new os layer function TimerCancel.
Lastly, copy the trust-level of this authorization into the client structure
so that it can be reached quickly for future access control decisions.
</p><p>
The embedding extension can determine the group to use for a new client in
the same way that we determined the trust level: get the authorization ID,
look it up, and if that succeeds, pluck the group out of the returned
authorization structure.
</p></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a id="Client_disconnection"></a>Chapter 3. Client disconnection</h1></div></div></div><p>
Use the existing ClientStateCallback to catch client disconnections. If the
client was using a generated authorization, decrement its reference count.
If the reference count is now zero, use the existing os layer function
TimerSet to start a timer to count down the timeout period for this
authorization. Record the timer ID for this authorization. When the timer
fires, the authorization should be freed, removing all
traces of it from the server.
</p><p>
There is a slight complication regarding the timeout because the timer
interface in the server allows for 32 bits worth of milliseconds, while
the timeout specified in GenerateAuthorization has 32 bits worth of seconds.
To handle this, if the specified time is more than the timer interface can
handle, the maximum possible timeout will be set, and time-remaining counter
for this authorization will be used to track the leftover part. When the
timer fires, it should first check to see if there is any leftover
time to wait. If there is, it should set another timer to the minimum of (the
maximum possible timeout) and the time remaining, and not do the revocation
yet.
</p></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a id="Resource_ID_Security"></a>Chapter 4. Resource ID Security</h1></div></div></div><p>
To implement the restriction that untrusted clients cannot access resources
of trusted clients, we add two new functions to dix: SecurityLookupIDByType
and SecurityLookupIDByClass. Hereafter we will use SecurityLookupID to refer
to both functions. In addition to the parameters of the existing LookupID
functions, these functions also take a pointer to the client doing the lookup,
and an access mode that conveys a high-level idea of what the client intends
to do with the resource (currently just read, write, destroy, and unknown).
Passing NullClient for the client turns off access checks. SecurityLookupID can
return NULL for two reasons: the resource doesn't exist, or it does but the
client isn't allowed to access it. The caller cannot tell the difference. Most
places in dix call these new lookup functions instead of the old LookupID,
which continue to do no access checking. Extension "Proc" functions should
probably use SecurityLookupID, not LookupID. Ddxen can continue to use
LookupID.
</p><p>
Inside SecurityLookupID, the function client -> CheckAccess is called
passing the client, resource id, resource type/class, resource value, and
access mode. CheckAccess returns the resource value if access is allowed,
else it returns NULL. The entire resource ID security policy of the Security
extension can be replaced by plugging in your own access decision function
here. This in combination with the access mode parameter should be enough to
implement a more traditional DAC (discretionary access control) policy.
</p><p>
Since we need client and access mode information to do access controlled
resource lookups, we add (and use) several other macros and functions that
parallel existing ones with the addition of the missing information. The list
includes SECURITY_VERIFY_GC, SECURITY_VERIFY_DRAWABLE,
SECURITY_VERIFY_GEOMETRABLE, SecurityLookupWindow,
SecurityLookupDrawable, and dixChangeGC. The dixChangeGC interface is
worth mentioning because in addition to a client parameter, we introduce a
pointer-to-union parameter that should let us eliminate the warnings that some
compilers give when you assign small integers to pointers, as the DoChangeGC
interface required. For more details, see the comment preceding dixChangeGC in
;<dix/gc.c;>.
</p><p>
If XCSECURITY is not defined (the Security extension is not being built),
the server uses essentially the same code as before for resource lookups.
</p></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a id="Extension_Security"></a>Chapter 5. Extension Security</h1></div></div></div><p>
A new field in the ExtensionEntry structure, Bool secure, tells whether the
extension is considered secure. It is initialized to FALSE by AddExtension.
The following new dix function can be used to set the secure field:
</p><div class="funcsynopsis"><a id="DeclareExtensionSecurity"></a><p><code class="funcdef">void <strong class="fsfunc">DeclareExtensionSecurity</strong>(</code>char <var class="pdparam"> *extname</var>, Bool <var class="pdparam">secure</var><code>)</code>;</p></div><p>
The name of the extension and the desired value of the secure field are
passed. If an extension is secure, a call to this function with
secure = TRUE will typically appear right after the call to
<code class="function">AddExtension</code>.
<a class="xref" href="#DeclareExtensionSecurity"><code class="function">DeclareExtensionSecurity</code></a>
should be called during server reset. It should not
be called after the first client has connected. Passing the name of an
extension that has not been initialized has no effect (the secure value will
not be remembered in case the extension is later initialized).
</p><p>
For untrusted clients, <code class="function">ProcListExtensions</code> omits
extensions that have secure = FALSE, and
<code class="function">ProcQueryExtension</code> reports that such
extensions don't exist.
</p><p>
To prevent untrusted clients from using extensions by guessing their major
opcode, one of two new Proc vectors are used by untusted clients,
<code class="function">UntrusedProcVector</code> and
<code class="function">SwappedUntrustedProcVector</code>. These have the same contents
as <code class="function">ProcVector</code> and
<code class="function">SwappedProcVector</code> respectively for the first 128
entries. Entries 128 through 255 are initialized to ProcBadRequest. If
<a class="xref" href="#DeclareExtensionSecurity"><code class="function">DeclareExtensionSecurity</code></a> is called with secure =
TRUE, that extension's dispatch function is plugged into the appropriate entry
so that the extension can be used. If
<a class="xref" href="#DeclareExtensionSecurity"><code class="function">DeclareExtensionSecurity</code></a> is called with secure =
FALSE, the appropriate entry is reset to ProcBadRequest.
</p><p>
Now we can explain why <a class="xref" href="#DeclareExtensionSecurity"><code class="function">DeclareExtensionSecurity</code></a>
should not be called after the first client connects. In some cases,
the Record extension gives clients a private copy of the proc vector,
which it then changes to intercept certain requests. Changing entries in
<code class="function">UntrusedProcVector</code> and
<code class="function">SwappedUntrustedProcVector</code> will have no effect on these
copied proc vectors. If we get to the point of needing an extension request
to control which extensions are secure, we'll need to invent a way to
get those copied proc vectors changed.
</p></div></div></body></html>
|