-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- From a security point of view, treating this differently has little value in
my mind. I believe policy writers just write both rules in place. I guess
you could argue that combining them together would allow a domain to write to
/dev/shm /tmp and /var/tmp and currently you could only write to one.
What do people think about this?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLzb8EACgkQrlYvE4MpobPhFwCg1IIHpepYnmNWIDXbmgKIk2sn
O4kAn2yMkxBzZ46bZ89nSffZvFDzhP7a
=aNMc
-----END PGP SIGNATURE-----
The shm you mention would be my only concern. I've thought about
introducing an shm_t or so instead but found little value.
Beyond that concern I'm OK with it.
On Feb 6, 2014 12:19 PM, "Daniel J Walsh" <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> - From a security point of view, treating this differently has little
> value in
> my mind. I believe policy writers just write both rules in place. I guess
> you could argue that combining them together would allow a domain to write
> to
> /dev/shm /tmp and /var/tmp and currently you could only write to one.
>
> What do people think about this?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLzb8EACgkQrlYvE4MpobPhFwCg1IIHpepYnmNWIDXbmgKIk2sn
> O4kAn2yMkxBzZ46bZ89nSffZvFDzhP7a
> =aNMc
> -----END PGP SIGNATURE-----
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20140206/26fbdabc/attachment.html
On 02/06/14 06:19, Daniel J Walsh wrote:
> - From a security point of view, treating this differently has little value in
> my mind. I believe policy writers just write both rules in place. I guess
> you could argue that combining them together would allow a domain to write to
> /dev/shm /tmp and /var/tmp and currently you could only write to one.
>
> What do people think about this?
I don't think I have any objections, though I'm eager to hear opinions. However, I think we should probably still keep /dev/shm separate.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/06/2014 02:51 PM, Christopher J. PeBenito wrote:
> On 02/06/14 06:19, Daniel J Walsh wrote:
>> - From a security point of view, treating this differently has little
>> value in my mind. I believe policy writers just write both rules in
>> place. I guess you could argue that combining them together would allow
>> a domain to write to /dev/shm /tmp and /var/tmp and currently you could
>> only write to one.
>>
>> What do people think about this?
>
> I don't think I have any objections, though I'm eager to hear opinions.
> However, I think we should probably still keep /dev/shm separate.
>
Well the goal is to prevent code like the following:
manage_dirs_pattern(aisexec_t, aisexec_tmp_t, aisexec_tmp_t)
manage_files_pattern(aisexec_t, aisexec_tmp_t, aisexec_tmp_t)
files_tmp_filetrans(aisexec_t, aisexec_tmp_t, { dir file })
manage_dirs_pattern(aisexec_t, aisexec_tmpfs_t, aisexec_tmpfs_t)
manage_files_pattern(aisexec_t, aisexec_tmpfs_t, aisexec_tmpfs_t)
fs_tmpfs_filetrans(aisexec_t, aisexec_tmpfs_t, { dir file })
We have this policy written everywhere. Having /dev/shm labeled differently
then /tmp means we still need to have this, which kills the idea.
I would like to know what the security difference is between writing content
to /dev/shm and /tmp? Does anyone actually do anything when getting an AVC
with a domain writing to /dev/shm other then allow the domain to write there?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLzrzgACgkQrlYvE4MpobMhWgCcCB6ovrsQfXq0fe/pdsZfCWH9
pcIAoIuipe2CH9bxC6yXBTHW3Eruwr7V
=o6Sg
-----END PGP SIGNATURE-----
Isn't one of the problems with tmpfs_t that it is not explicit enough? Some
of the tmpfs_t grants can/are due to other tmpfs mounts. Using a shm_t at
least tells people what it is for.
On Feb 6, 2014 5:38 PM, "Daniel J Walsh" <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/06/2014 02:51 PM, Christopher J. PeBenito wrote:
> > On 02/06/14 06:19, Daniel J Walsh wrote:
> >> - From a security point of view, treating this differently has little
> >> value in my mind. I believe policy writers just write both rules in
> >> place. I guess you could argue that combining them together would allow
> >> a domain to write to /dev/shm /tmp and /var/tmp and currently you could
> >> only write to one.
> >>
> >> What do people think about this?
> >
> > I don't think I have any objections, though I'm eager to hear opinions.
> > However, I think we should probably still keep /dev/shm separate.
> >
> Well the goal is to prevent code like the following:
>
> manage_dirs_pattern(aisexec_t, aisexec_tmp_t, aisexec_tmp_t)
> manage_files_pattern(aisexec_t, aisexec_tmp_t, aisexec_tmp_t)
> files_tmp_filetrans(aisexec_t, aisexec_tmp_t, { dir file })
>
> manage_dirs_pattern(aisexec_t, aisexec_tmpfs_t, aisexec_tmpfs_t)
> manage_files_pattern(aisexec_t, aisexec_tmpfs_t, aisexec_tmpfs_t)
> fs_tmpfs_filetrans(aisexec_t, aisexec_tmpfs_t, { dir file })
>
> We have this policy written everywhere. Having /dev/shm labeled
> differently
> then /tmp means we still need to have this, which kills the idea.
>
> I would like to know what the security difference is between writing
> content
> to /dev/shm and /tmp? Does anyone actually do anything when getting an AVC
> with a domain writing to /dev/shm other then allow the domain to write
> there?
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLzrzgACgkQrlYvE4MpobMhWgCcCB6ovrsQfXq0fe/pdsZfCWH9
> pcIAoIuipe2CH9bxC6yXBTHW3Eruwr7V
> =o6Sg
> -----END PGP SIGNATURE-----
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20140206/85641644/attachment.html
On 02/06/14 10:50, Daniel J Walsh wrote:
> On 02/06/2014 02:51 PM, Christopher J. PeBenito wrote:
>> On 02/06/14 06:19, Daniel J Walsh wrote:
>>> - From a security point of view, treating this differently has little
>>> value in my mind. I believe policy writers just write both rules in
>>> place. I guess you could argue that combining them together would allow
>>> a domain to write to /dev/shm /tmp and /var/tmp and currently you could
>>> only write to one.
>>>
>>> What do people think about this?
>
>> I don't think I have any objections, though I'm eager to hear opinions.
>> However, I think we should probably still keep /dev/shm separate.
>
> Well the goal is to prevent code like the following:
>
> manage_dirs_pattern(aisexec_t, aisexec_tmp_t, aisexec_tmp_t)
> manage_files_pattern(aisexec_t, aisexec_tmp_t, aisexec_tmp_t)
> files_tmp_filetrans(aisexec_t, aisexec_tmp_t, { dir file })
>
> manage_dirs_pattern(aisexec_t, aisexec_tmpfs_t, aisexec_tmpfs_t)
> manage_files_pattern(aisexec_t, aisexec_tmpfs_t, aisexec_tmpfs_t)
> fs_tmpfs_filetrans(aisexec_t, aisexec_tmpfs_t, { dir file })
>
> We have this policy written everywhere. Having /dev/shm labeled differently
> then /tmp means we still need to have this, which kills the idea.
I understand. I'd like to get rid of the duplication too. This prompts the question, how much of the tmpfs stuff is due to standard /dev/shm use (i.e. SysV shared memory) vs. people mounting a tmpfs at /tmp? It might make sense to keep the fs labeled tmpfs_t, but filetrans to foo_tmp_t. And then when we have a case of a domain that has tmpfs and tmp objects, then they can still be split out into foo_tmp_t and foo_tmpfs_t if another domain accesses it's tmpfs files.
> I would like to know what the security difference is between writing content
> to /dev/shm and /tmp? Does anyone actually do anything when getting an AVC
> with a domain writing to /dev/shm other then allow the domain to write there?
A shared memory segment is different than a temp file.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/07/2014 10:36 AM, Christopher J. PeBenito wrote:
> On 02/06/14 10:50, Daniel J Walsh wrote:
>> On 02/06/2014 02:51 PM, Christopher J. PeBenito wrote:
>>> On 02/06/14 06:19, Daniel J Walsh wrote:
>>>> - From a security point of view, treating this differently has
>>>> little value in my mind. I believe policy writers just write both
>>>> rules in place. I guess you could argue that combining them together
>>>> would allow a domain to write to /dev/shm /tmp and /var/tmp and
>>>> currently you could only write to one.
>>>>
>>>> What do people think about this?
>>
>>> I don't think I have any objections, though I'm eager to hear
>>> opinions. However, I think we should probably still keep /dev/shm
>>> separate.
>>
>> Well the goal is to prevent code like the following:
>>
>> manage_dirs_pattern(aisexec_t, aisexec_tmp_t, aisexec_tmp_t)
>> manage_files_pattern(aisexec_t, aisexec_tmp_t, aisexec_tmp_t)
>> files_tmp_filetrans(aisexec_t, aisexec_tmp_t, { dir file })
>>
>> manage_dirs_pattern(aisexec_t, aisexec_tmpfs_t, aisexec_tmpfs_t)
>> manage_files_pattern(aisexec_t, aisexec_tmpfs_t, aisexec_tmpfs_t)
>> fs_tmpfs_filetrans(aisexec_t, aisexec_tmpfs_t, { dir file })
>>
>> We have this policy written everywhere. Having /dev/shm labeled
>> differently then /tmp means we still need to have this, which kills the
>> idea.
>
> I understand. I'd like to get rid of the duplication too. This prompts
> the question, how much of the tmpfs stuff is due to standard /dev/shm use
> (i.e. SysV shared memory) vs. people mounting a tmpfs at /tmp? It might
> make sense to keep the fs labeled tmpfs_t, but filetrans to foo_tmp_t. And
> then when we have a case of a domain that has tmpfs and tmp objects, then
> they can still be split out into foo_tmp_t and foo_tmpfs_t if another
> domain accesses it's tmpfs files.
>
>> I would like to know what the security difference is between writing
>> content to /dev/shm and /tmp? Does anyone actually do anything when
>> getting an AVC with a domain writing to /dev/shm other then allow the
>> domain to write there?
>
> A shared memory segment is different than a temp file.
>
Yes /dev/shm is mainly for SysV Shared Memory, which we were trying to stop
labeling altogether. But it turns out that these could be attacked if they do
not have labeling. Which means we have to add file type transitions to all
objects that use SysV Shared Memory. This is actually what caused me to ask
for this in the first place.
Labeling /dev/shm as shm_t or tmpfs_t and then transitioning to foobar_tmp_t
is fine with me, also. Especially if we change files_tmp_filetrans to call
fs_tmpfs_filetrans :^).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlL6QzEACgkQrlYvE4MpobP8EQCfXyAjZsaqQAbzLtXwsBcZqQ0j
7JYAn30i3yg42tJp4amdzNjHeNCGi25Z
=K+L+
-----END PGP SIGNATURE-----
On 2/11/2014 10:35 AM, Daniel J Walsh wrote:
> On 02/07/2014 10:36 AM, Christopher J. PeBenito wrote:
>> On 02/06/14 10:50, Daniel J Walsh wrote:
>>> On 02/06/2014 02:51 PM, Christopher J. PeBenito wrote:
>>>> On 02/06/14 06:19, Daniel J Walsh wrote:
>>>>> - From a security point of view, treating this differently has
>>>>> little value in my mind. I believe policy writers just write both
>>>>> rules in place. I guess you could argue that combining them together
>>>>> would allow a domain to write to /dev/shm /tmp and /var/tmp and
>>>>> currently you could only write to one.
>>>>>
>>>>> What do people think about this?
>>>
>>>> I don't think I have any objections, though I'm eager to hear
>>>> opinions. However, I think we should probably still keep /dev/shm
>>>> separate.
>>>
>>> Well the goal is to prevent code like the following:
>>>
>>> manage_dirs_pattern(aisexec_t, aisexec_tmp_t, aisexec_tmp_t)
>>> manage_files_pattern(aisexec_t, aisexec_tmp_t, aisexec_tmp_t)
>>> files_tmp_filetrans(aisexec_t, aisexec_tmp_t, { dir file })
>>>
>>> manage_dirs_pattern(aisexec_t, aisexec_tmpfs_t, aisexec_tmpfs_t)
>>> manage_files_pattern(aisexec_t, aisexec_tmpfs_t, aisexec_tmpfs_t)
>>> fs_tmpfs_filetrans(aisexec_t, aisexec_tmpfs_t, { dir file })
>>>
>>> We have this policy written everywhere. Having /dev/shm labeled
>>> differently then /tmp means we still need to have this, which kills the
>>> idea.
>
>> I understand. I'd like to get rid of the duplication too. This prompts
>> the question, how much of the tmpfs stuff is due to standard /dev/shm use
>> (i.e. SysV shared memory) vs. people mounting a tmpfs at /tmp? It might
>> make sense to keep the fs labeled tmpfs_t, but filetrans to foo_tmp_t. And
>> then when we have a case of a domain that has tmpfs and tmp objects, then
>> they can still be split out into foo_tmp_t and foo_tmpfs_t if another
>> domain accesses it's tmpfs files.
>
>>> I would like to know what the security difference is between writing
>>> content to /dev/shm and /tmp? Does anyone actually do anything when
>>> getting an AVC with a domain writing to /dev/shm other then allow the
>>> domain to write there?
>
>> A shared memory segment is different than a temp file.
>
> Yes /dev/shm is mainly for SysV Shared Memory, which we were trying to stop
> labeling altogether. But it turns out that these could be attacked if they do
> not have labeling. Which means we have to add file type transitions to all
> objects that use SysV Shared Memory. This is actually what caused me to ask
> for this in the first place.
>
> Labeling /dev/shm as shm_t or tmpfs_t and then transitioning to foobar_tmp_t
> is fine with me, also. Especially if we change files_tmp_filetrans to call
> fs_tmpfs_filetrans :^).
I've been poking at this for a while, and what I've concluded is that we can merge the tmpfs types into tmp type, as long as the domain doesn't have any shm usage, under the assumption that the domain is using tmpfs as a regular tmp dir. If I'm counting correctly, it looks like half the domains that have *_tmpfs_t usage could potentially merge it into their *_tmp_t.
What's odd is that I found that some domains that do have shm rules but don't have tmpfs rules, which makes me wonder if the shm rules are valid (or can you do shm w/o tmpfs usage?).
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com