Date: Mon, 25 Aug 2003 14:07:31 -0700 (PDT) From: Robert Watson <rwatson@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 36911 for review Message-ID: <200308252107.h7PL7V9I097307@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=36911 Change 36911 by rwatson@rwatson_paprika on 2003/08/25 14:06:49 Cleanup to general socket description, and System V IPC namespace discussion. Affected files ... .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/arch-handbook/secarch/chapter.sgml#3 edit Differences ... ==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/arch-handbook/secarch/chapter.sgml#3 (text+ko) ==== @@ -1817,10 +1817,20 @@ Individual protocols implement protections appropriate to their namespaces and semantics, including controlling access to the namespace, read and write privileges, etc. + Namespaces may be local, such as the file system namespace, + or be distributed across many nodes, as is the case with the + IPv4 network implementation. As sockets are referenced by file descriptors, they may be inheritted across fork() and exec() operations, as well as passed to other processes using UNIX Domain Socket file - descriptor passing.</para> + descriptor passing. + In some situations, a reference to a socket via a file + descriptor is sufficient to authorize use of the socket by + a process; in others, the process must also have appropriate + privilege by virtue of its process credential. + As such, processes with access to sockets, as with other + objects, should take care to permit only authorized processes + to gain access to the sockets.</para> </sect2> <sect2 id="secarch-sysvipc"> @@ -1845,18 +1855,12 @@ references to the object cannot be created, however. Objects may also be created with the IPC_PRIVATE name, specifying that they should not be accessible to any other - processes.</para> - -<para> -Three kinds of System V IPC objects: semaphores, message queues, and -shared memory segments. - -Other than preventing collisions for live objects, no protections are -placed on the namespace itself, which may permit denial of service or -spoofing attacks to take place; unfortunately, this is a property of -the industry-standard APIs that is not easily corrected without -polyinstantiation. -</para> + processes. + As the System V IPC namespace is not controlled, applications + may be subject to spoofing, reuse, and race attacks by + other processes who have equal ability to modify the + namespace; unfortunately, this is a property of the + industry-standard API that is not easily corrected.</para> <para>Each object has an ipc permissions object, holding creator uid, creator gid, owner uid and owner gid.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200308252107.h7PL7V9I097307>