1238 |
your own protocols, and improvements to the above protocol against. |
your own protocols, and improvements to the above protocol against. |
1239 |
|
|
1240 |
|
|
1241 |
|
\subsubsection{The trust rule} |
1242 |
|
|
1243 |
|
The protocol to copy a capability from one client to another task has |
1244 |
|
a dramatic consequence on the design of the Hurd interfaces. |
1245 |
|
|
1246 |
|
Because the receiver of the capability must make blocking calls to the |
1247 |
|
server providing the capability, the receiver of the capability |
1248 |
|
\emph{must} trust the server providing the capability. |
1249 |
|
|
1250 |
|
This means also: If the receiver of a capability does not trust the |
1251 |
|
server providing the capability, it \emph{must not} accept it. |
1252 |
|
|
1253 |
|
The consequence is that normally, servers can not accept capabilities |
1254 |
|
from clients, unless they are provided by a specific trusted server. |
1255 |
|
This can be the \texttt{task} or \texttt{auth} server for example. |
1256 |
|
|
1257 |
|
This rule is even true if the receiver does not actually want to use |
1258 |
|
the capability for anything. Just accepting the capability requires |
1259 |
|
trusting the server providing it already. |
1260 |
|
|
1261 |
|
In the Hurd on Mach, ports (which are analogous to capabilities in |
1262 |
|
this context) can be passed around freely. There is no security risk |
1263 |
|
in accepting a port from any source, because the kernel implements |
1264 |
|
them as protected objects. Using a port by sending blocking messages |
1265 |
|
to it requires trust, but simply storing the port on the server side |
1266 |
|
does not. |
1267 |
|
|
1268 |
|
This is different in the Hurd on L4: A server must not accept |
1269 |
|
capabilities unless it trusts the server providing them. Because |
1270 |
|
capabilities are used for many different purposes (remote objects, |
1271 |
|
authentication, identification), one has to be very careful in |
1272 |
|
designing the interfaces. The Hurd interfaces on Mach use ports in a |
1273 |
|
way that is not possible on L4. Such interfaces need to be |
1274 |
|
redesigned. |
1275 |
|
|
1276 |
|
Often, redesigning such an interface also fixes some other security |
1277 |
|
problems that exists with in the Hurd on L4, in particular DoS |
1278 |
|
attacks. A good part of this paper is about redesigning the Hurd to |
1279 |
|
avoid storing untrusted capabilities on the server side. |
1280 |
|
|
1281 |
|
\begin{comment} |
1282 |
|
Examples are: |
1283 |
|
|
1284 |
|
\begin{itemize} |
1285 |
|
\item The new authentication protocol, which eliminates the need for |
1286 |
|
a rendezvous port and is not only faster, but also does not |
1287 |
|
require the server to block on the client anymore (see section |
1288 |
|
\ref{auth} on page \pageref{auth}). |
1289 |
|
|
1290 |
|
\item The signal handling, which does not require the \texttt{proc} |
1291 |
|
server to hold the signal port for every task anymore (see section |
1292 |
|
\ref{signals} on page \pageref{signals}). |
1293 |
|
|
1294 |
|
\item The new exec protocol, which eliminates the need to pass all |
1295 |
|
capabilities that need to be transfered to the new executable from |
1296 |
|
the old program to the filesystem server, and then to the |
1297 |
|
\texttt{exec} server (see section \ref{exec} on page |
1298 |
|
\pageref{exec}). |
1299 |
|
|
1300 |
|
\item The new way to implement Unix Domain Sockets, which don't |
1301 |
|
require a trusted system server, so that descriptor passing (which |
1302 |
|
is really capability passing) can work (see section |
1303 |
|
\ref{unixdomainsockets} on page \pageref{unixdomainsockets}. |
1304 |
|
|
1305 |
|
\item The way parent and child filesystem are linked to each other, |
1306 |
|
in other words: how mounting a filesystem works (see section |
1307 |
|
\ref{xfslookup} on page \pageref{xfslookup}). |
1308 |
|
|
1309 |
|
\item The replacement for the \verb/file_reparent()/ RPC (see |
1310 |
|
section \ref{reparenting} on page \pageref{reparenting}). |
1311 |
|
\end{itemize} |
1312 |
|
\end{comment} |
1313 |
|
|
1314 |
\subsection{Synchronous IPC} |
\subsection{Synchronous IPC} |
1315 |
|
|
1316 |
The Hurd only needs synchronous IPC. Asynchronous IPC is usually not |
The Hurd only needs synchronous IPC. Asynchronous IPC is usually not |
1829 |
|
|
1830 |
|
|
1831 |
\subsubsection{Signals} |
\subsubsection{Signals} |
1832 |
|
\label{signals} |
1833 |
|
|
1834 |
Each process can register the thread ID of a signal thread with the |
Each process can register the thread ID of a signal thread with the |
1835 |
\texttt{proc} server. The proc server will give the signal thread ID |
\texttt{proc} server. The proc server will give the signal thread ID |
1895 |
|
|
1896 |
|
|
1897 |
\subsubsection{The \texttt{exec()} function} |
\subsubsection{The \texttt{exec()} function} |
1898 |
|
\label{exec} |
1899 |
|
|
1900 |
The exec() operation will be done locally in a task. Traditionally, |
The exec() operation will be done locally in a task. Traditionally, |
1901 |
exec() overlays the same task with a new process image, because |
exec() overlays the same task with a new process image, because |
1980 |
|
|
1981 |
|
|
1982 |
\subsection{Unix Domain Sockets} |
\subsection{Unix Domain Sockets} |
1983 |
|
\label{unixdomainsockets} |
1984 |
|
|
1985 |
In the Hurd on Mach, there was a global pflocal server that provided |
In the Hurd on Mach, there was a global pflocal server that provided |
1986 |
unix domain sockets and pipes to all users. This will not work very |
unix domain sockets and pipes to all users. This will not work very |
2129 |
|
|
2130 |
|
|
2131 |
\subsubsection{Reparenting} |
\subsubsection{Reparenting} |
2132 |
|
\label{reparenting} |
2133 |
|
|
2134 |
The Hurd on Mach contains a curious RPC, \verb/file_reparent/, which |
The Hurd on Mach contains a curious RPC, \verb/file_reparent/, which |
2135 |
allows you to create a new capability for the same node, with the |
allows you to create a new capability for the same node, with the |