* Sec context of unix domain sockets
@ 2011-07-04 16:07 Martin Christian
2011-07-11 14:21 ` Stephen Smalley
0 siblings, 1 reply; 6+ messages in thread
From: Martin Christian @ 2011-07-04 16:07 UTC (permalink / raw)
To: selinux
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
how are unix domain sockets handeled regarding the default context?
Please comment on the following statement or fill my gaps:
a. Processes inherit the label of their parent, except for the init
process which gets the label of the kernel sid
b. Ext{2-4} files/directories get the label of their parent directory.
Root (/) gets its label from the file system context (fs_use) on creation.
c. Inet sockets get the label specified with the portcon statement or
the context of kernel sid (?)
d. Unix domain sockets are split in 2 parts: the socket file is treated
as b. The socket object gets the label of the kernel sid (?) Is there a
way to define the context of a unix domain socket object? The only way I
can see would be to define a transition.
Explanations and clarification much appreciated.
Martin.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOEeU0AAoJEGpTkDITRjmo14EIAJstcDIklJK8ZSRz+4nGqd+s
VWtrbzE71RXuSnWJZZo77Hx2Fs4jqh5dEKED6gJdiVE/5yQb5VskQ+b6wFHj9q87
IKihqGioZiP1rLDer5Wyhv/ZgJ7uhJab5j6xNlRgSy8JphQVyG+7piJIkbX2ui3q
TSC8vh55WQe2jqvtznXbWlbxDv924t+rJC3suNCIn5dvTFv2zfmMwTRfzp7ItZYM
93h3ZWlq2faYPhHE3eP68VmLUINzW20hRhIl2J4aIqzewa3x27zPg+0yJ1T6ghrV
E2NgH+eH5LyFZ6ddqMGlnu18VGuGfsSwMMCz7/ideiEJpYCXZNGDsaE7X9e5U/Y=
=wEgh
-----END PGP SIGNATURE-----
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Sec context of unix domain sockets 2011-07-04 16:07 Sec context of unix domain sockets Martin Christian @ 2011-07-11 14:21 ` Stephen Smalley 2011-07-12 16:57 ` Martin Christian 0 siblings, 1 reply; 6+ messages in thread From: Stephen Smalley @ 2011-07-11 14:21 UTC (permalink / raw) To: Martin Christian; +Cc: selinux On Mon, 2011-07-04 at 18:07 +0200, Martin Christian wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > how are unix domain sockets handeled regarding the default context? > Please comment on the following statement or fill my gaps: Aside from the code, useful (but possibly out of date) documentation can be found in the technical reports available from: http://www.nsa.gov/research/selinux/docs.shtml In particular, the original tech report: http://www.nsa.gov/research/_files/selinux/papers/slinux-abs.shtml and the supplemental one for the port to LSM: http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml can be quite helpful. There may however be discrepancies between what they describe and the current implementation. There have been changes over time, so knowing exactly what kernel you are using is important. > a. Processes inherit the label of their parent, except for the init > process which gets the label of the kernel sid On fork, a process inherits the label of its creator/parent. On exec, a process may transition to another label based on policy statements (type_transition, role_transition, range_transition) or by calling setexeccon(3) if permitted by policy prior to invoking exec. At any time, a process may invoke setcon(3) to switch its label (if permitted by policy) although this practice is generally discouraged - exec-based transitions are preferred. The initial task starts with the kernel SID, but the "init" process will typically transition into its own unique context (e.g. init_t) when the init binary is executed after the policy has been loaded. Some init programs re-exec themselves after loading policy, while in other cases the initial policy load is performed by the initrd/initramfs script prior to mounting the real root and executing the real init program. > b. Ext{2-4} files/directories get the label of their parent directory. > Root (/) gets its label from the file system context (fs_use) on creation. You need to distinguish the components of the security context, as they have different default behaviors. The user field is inherited from the creating process. The role field is presently unused for files and is always set to the predefined object_r role, although there have been proposals to change this behavior. The type field defaults to the type of the parent directory if no matching type_transition rule was specified in the policy. The range/level field defaults to the low/current level of the creating process if no matching range_transition rule was specified in the policy. The above describes the default behavior for labeling files (inodes) upon creation for any filesystem type that supports labeling, not just ext[2-4]. This default behavior can be overridden by a process by calling setfscreatecon(3) prior to creating the file, if permitted by policy. For existing files, the label is determined from the xattr value associated with the file. If there is no xattr value set on the file, then the file is treated as being labeled with the default file SID for the filesystem. By default, this is the "file" initial SID, which is mapped to a context by the policy. This default may be overridden via the defcontext= mount option on a per-mount basis. So the root directory may default to this value until you have explicitly labeled it. This differs however from the context specified in the fs_use_xattr statement, which is the context of the filesystem/superblock. > c. Inet sockets get the label specified with the portcon statement or > the context of kernel sid (?) Um, no. Sockets are typically labeled with the context of the creating process, although support for socket type transitions was recently added. portcon statements are only used to label ports, not sockets, and then you have a permission check between a socket SID and a port SID to control operations such as binding and connecting to specific ports. Some sockets may be labeled with the kernel SID to reflect the fact that they are kernel-internal sockets that are not directly exposed to applications. > d. Unix domain sockets are split in 2 parts: the socket file is treated > as b. The socket object gets the label of the kernel sid (?) Is there a > way to define the context of a unix domain socket object? The only way I > can see would be to define a transition. The socket file is merely a way to name/address the socket, and isn't even strictly required - you can use the abstract namespace instead and thus avoid any use of the filesystem for Unix/local domain sockets. When you use a socket file, yes, it gets labeled in accordance with the usual file labeling rules as per b. The socket object is labeled as per c. Security-aware applications can use setsockcreatecon(3) to explicitly label sockets they create. > Explanations and clarification much appreciated. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Sec context of unix domain sockets 2011-07-11 14:21 ` Stephen Smalley @ 2011-07-12 16:57 ` Martin Christian 2011-07-12 17:23 ` Stephen Smalley 0 siblings, 1 reply; 6+ messages in thread From: Martin Christian @ 2011-07-12 16:57 UTC (permalink / raw) To: Stephen Smalley; +Cc: selinux Thanks Stephen for your extensive explanation. Maybe you - or someone else on the list, of course - could help me with a unix socket problem. I'm still not sure whether your explanation (and documentation you referred to) is missing something or if our policy has a bug: We developed a targeted policy for a system with 2 confined services: * syslog is running in domain syslog_t and creates a unix domain socket in /dev/log. * serva is running in domain serva_t and needs to send messages to syslog via the socket. The rest of the system is unconfined with access to everything. Of course, there is a little bit more, but everything else is working just fine. Now, I get the following AVC message: [YYY] type=1400 audit(XXX): avc: denied { sendto } for pid=1879 comm="serva" path="/dev/log" scontext=system_u:object_r:serva_t:s1 tcontext=system_u:object_r:unconfined_t:s1 tclass=unix_dgram_socket What I don't understand is, why tcontext is not syslog_t but unconfined_t? I thought the following process applies: 1. syslog creates a listing socket with label syslog_t. 2. serva creates a socket for sending with label serva_t. 3. In order to send a message serva would require sendto permissions on syslog_t. There is certainly some more in between these steps, but nothing that would make /dev/log labelled with unconfined_t, is it? Regards, Martin. Am 11.07.2011 16:21, schrieb Stephen Smalley: > On Mon, 2011-07-04 at 18:07 +0200, Martin Christian wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> how are unix domain sockets handeled regarding the default context? >> Please comment on the following statement or fill my gaps: > > Aside from the code, useful (but possibly out of date) documentation can > be found in the technical reports available from: > http://www.nsa.gov/research/selinux/docs.shtml > > In particular, the original tech report: > http://www.nsa.gov/research/_files/selinux/papers/slinux-abs.shtml > and the supplemental one for the port to LSM: > http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml > can be quite helpful. There may however be discrepancies between what > they describe and the current implementation. There have been changes > over time, so knowing exactly what kernel you are using is important. > >> a. Processes inherit the label of their parent, except for the init >> process which gets the label of the kernel sid > > On fork, a process inherits the label of its creator/parent. > On exec, a process may transition to another label based on policy > statements (type_transition, role_transition, range_transition) or by > calling setexeccon(3) if permitted by policy prior to invoking exec. > At any time, a process may invoke setcon(3) to switch its label (if > permitted by policy) although this practice is generally discouraged - > exec-based transitions are preferred. > > The initial task starts with the kernel SID, but the "init" process will > typically transition into its own unique context (e.g. init_t) when the > init binary is executed after the policy has been loaded. Some init > programs re-exec themselves after loading policy, while in other cases > the initial policy load is performed by the initrd/initramfs script > prior to mounting the real root and executing the real init program. > >> b. Ext{2-4} files/directories get the label of their parent directory. >> Root (/) gets its label from the file system context (fs_use) on creation. > > You need to distinguish the components of the security context, as they > have different default behaviors. The user field is inherited from the > creating process. The role field is presently unused for files and is > always set to the predefined object_r role, although there have been > proposals to change this behavior. The type field defaults to the type > of the parent directory if no matching type_transition rule was > specified in the policy. The range/level field defaults to the > low/current level of the creating process if no matching > range_transition rule was specified in the policy. > > The above describes the default behavior for labeling files (inodes) > upon creation for any filesystem type that supports labeling, not just > ext[2-4]. This default behavior can be overridden by a process by > calling setfscreatecon(3) prior to creating the file, if permitted by > policy. > > For existing files, the label is determined from the xattr value > associated with the file. If there is no xattr value set on the file, > then the file is treated as being labeled with the default file SID for > the filesystem. By default, this is the "file" initial SID, which is > mapped to a context by the policy. This default may be overridden via > the defcontext= mount option on a per-mount basis. So the root > directory may default to this value until you have explicitly labeled > it. This differs however from the context specified in the fs_use_xattr > statement, which is the context of the filesystem/superblock. > >> c. Inet sockets get the label specified with the portcon statement or >> the context of kernel sid (?) > > Um, no. Sockets are typically labeled with the context of the creating > process, although support for socket type transitions was recently > added. portcon statements are only used to label ports, not sockets, > and then you have a permission check between a socket SID and a port SID > to control operations such as binding and connecting to specific ports. > Some sockets may be labeled with the kernel SID to reflect the fact that > they are kernel-internal sockets that are not directly exposed to > applications. > >> d. Unix domain sockets are split in 2 parts: the socket file is treated >> as b. The socket object gets the label of the kernel sid (?) Is there a >> way to define the context of a unix domain socket object? The only way I >> can see would be to define a transition. > > The socket file is merely a way to name/address the socket, and isn't > even strictly required - you can use the abstract namespace instead and > thus avoid any use of the filesystem for Unix/local domain sockets. > When you use a socket file, yes, it gets labeled in accordance with the > usual file labeling rules as per b. The socket object is labeled as per > c. Security-aware applications can use setsockcreatecon(3) to > explicitly label sockets they create. > >> Explanations and clarification much appreciated. > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Sec context of unix domain sockets 2011-07-12 16:57 ` Martin Christian @ 2011-07-12 17:23 ` Stephen Smalley 2011-07-13 13:12 ` Martin Christian 0 siblings, 1 reply; 6+ messages in thread From: Stephen Smalley @ 2011-07-12 17:23 UTC (permalink / raw) To: Martin Christian; +Cc: selinux On Tue, 2011-07-12 at 18:57 +0200, Martin Christian wrote: > Thanks Stephen for your extensive explanation. > > Maybe you - or someone else on the list, of course - could help me with > a unix socket problem. I'm still not sure whether your explanation (and > documentation you referred to) is missing something or if our policy has > a bug: > > We developed a targeted policy for a system with 2 confined services: > > * syslog is running in domain syslog_t and creates a unix domain socket > in /dev/log. > > * serva is running in domain serva_t and needs to send messages to > syslog via the socket. > > The rest of the system is unconfined with access to everything. Of > course, there is a little bit more, but everything else is working just > fine. > > Now, I get the following AVC message: > > [YYY] type=1400 audit(XXX): avc: denied { sendto } for > pid=1879 comm="serva" path="/dev/log" > scontext=system_u:object_r:serva_t:s1 > tcontext=system_u:object_r:unconfined_t:s1 > tclass=unix_dgram_socket > > What I don't understand is, why tcontext is not syslog_t but unconfined_t? > > I thought the following process applies: > 1. syslog creates a listing socket with label syslog_t. > 2. serva creates a socket for sending with label serva_t. > 3. In order to send a message serva would require sendto permissions on > syslog_t. > > There is certainly some more in between these steps, but nothing that > would make /dev/log labelled with unconfined_t, is it? The socket is labeled when it is created. So if it is created by a process that runs in unconfined_t and then inherited by your syslog as an open file descriptor, you would get the behavior you describe. With some init programs (e.g. systemd, Android init), we've had to instrument the init program to properly label sockets because the init program creates the socket and hands it to the service rather than having the service daemon create the socket. If that isn't your situation, then another possibility would be that syslog is in fact running in unconfined_t due to a policy or labeling error. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Sec context of unix domain sockets 2011-07-12 17:23 ` Stephen Smalley @ 2011-07-13 13:12 ` Martin Christian 2011-07-13 14:02 ` Stephen Smalley 0 siblings, 1 reply; 6+ messages in thread From: Martin Christian @ 2011-07-13 13:12 UTC (permalink / raw) To: Stephen Smalley; +Cc: selinux -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Stephen, you pointed me into the right direction: We have a startup log daemon which gets replaced by syslog at the end of the boot process. The AVC message occurs when /dev/log still belongs to the startup log daemon. Thanks for your hint! What I was missing all the time during my investigation was a tool, which displays the security labels of unix domain sockets. Is there nothing like this around? netstat doesn't seem to support selinux labels (an option -Z), does it? Maybe I could reserve some time in our schedule to add such an option to netstat. Regards, Martin. Am 12.07.2011 19:23, schrieb Stephen Smalley: > On Tue, 2011-07-12 at 18:57 +0200, Martin Christian wrote: >> Thanks Stephen for your extensive explanation. >> >> Maybe you - or someone else on the list, of course - could help me with >> a unix socket problem. I'm still not sure whether your explanation (and >> documentation you referred to) is missing something or if our policy has >> a bug: >> >> We developed a targeted policy for a system with 2 confined services: >> >> * syslog is running in domain syslog_t and creates a unix domain socket >> in /dev/log. >> >> * serva is running in domain serva_t and needs to send messages to >> syslog via the socket. >> >> The rest of the system is unconfined with access to everything. Of >> course, there is a little bit more, but everything else is working just >> fine. >> >> Now, I get the following AVC message: >> >> [YYY] type=1400 audit(XXX): avc: denied { sendto } for >> pid=1879 comm="serva" path="/dev/log" >> scontext=system_u:object_r:serva_t:s1 >> tcontext=system_u:object_r:unconfined_t:s1 >> tclass=unix_dgram_socket >> >> What I don't understand is, why tcontext is not syslog_t but unconfined_t? >> >> I thought the following process applies: >> 1. syslog creates a listing socket with label syslog_t. >> 2. serva creates a socket for sending with label serva_t. >> 3. In order to send a message serva would require sendto permissions on >> syslog_t. >> >> There is certainly some more in between these steps, but nothing that >> would make /dev/log labelled with unconfined_t, is it? > > The socket is labeled when it is created. So if it is created by a > process that runs in unconfined_t and then inherited by your syslog as > an open file descriptor, you would get the behavior you describe. With > some init programs (e.g. systemd, Android init), we've had to instrument > the init program to properly label sockets because the init program > creates the socket and hands it to the service rather than having the > service daemon create the socket. > > If that isn't your situation, then another possibility would be that > syslog is in fact running in unconfined_t due to a policy or labeling > error. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOHZnSAAoJEGpTkDITRjmoIgIIAJCcO1DIP6sidNmN9vbGfWTn G3UCAWOtKxJ3ACBbGbkOHkvxeMz6BD+YLBLuuvKWdyUqrsAnkQukB8/TmrSuyEnv 1/nuINEZmklqM6SQdYcoFWwy/nNBTYYKWbCqeCJbwrtdUXZ2EsDoKOQ4D6l4n2wU htq2x6S613yChGOsZEPYIRjH8RIVkzLI4yUgGXZM99HDRuTDPyMB7jcKVeiDfeBy xq6LcSFngjnhkr1uAyPsNE4qKRyAQ3Cl+QhlbqVm/PWm2V7QWnDtCqUZI73DmM5I ocCYyufDUWsjiuC0BZRrDytGzx72TeT4SgQ3s7Mh8CgHe6Hdow++bDCVaE0tFu4= =tyJ5 -----END PGP SIGNATURE----- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Sec context of unix domain sockets 2011-07-13 13:12 ` Martin Christian @ 2011-07-13 14:02 ` Stephen Smalley 0 siblings, 0 replies; 6+ messages in thread From: Stephen Smalley @ 2011-07-13 14:02 UTC (permalink / raw) To: Martin Christian; +Cc: selinux On Wed, 2011-07-13 at 15:12 +0200, Martin Christian wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Stephen, > > you pointed me into the right direction: We have a startup log daemon > which gets replaced by syslog at the end of the boot process. The AVC > message occurs when /dev/log still belongs to the startup log daemon. > Thanks for your hint! > > What I was missing all the time during my investigation was a tool, > which displays the security labels of unix domain sockets. Is there > nothing like this around? netstat doesn't seem to support selinux labels > (an option -Z), does it? Maybe I could reserve some time in our schedule > to add such an option to netstat. The Fedora netstat program has a -Z option, but the implementation appears to read the context of the owning process (via /proc/<pid>/attr/current), not necessarily the context of the individual socket. Not sure you can get to that information from any process other than the owning one without reading kernel memory. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-07-13 14:02 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-07-04 16:07 Sec context of unix domain sockets Martin Christian 2011-07-11 14:21 ` Stephen Smalley 2011-07-12 16:57 ` Martin Christian 2011-07-12 17:23 ` Stephen Smalley 2011-07-13 13:12 ` Martin Christian 2011-07-13 14:02 ` Stephen Smalley
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.