Sec context of unix domain sockets

Sec context of unix domain sockets

[Martin Christian]

-----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.

Re: Sec context of unix domain sockets

[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.

-- 
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.

Re: Sec context of unix domain sockets

[Martin Christian]

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.

Re: Sec context of unix domain sockets

[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.

-- 
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.

Re: Sec context of unix domain sockets

[Martin Christian]

-----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.

Re: Sec context of unix domain sockets

[Stephen Smalley]

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.