On Mon, May 08, 2017 at 09:42:09AM -0400, Stephen Smalley wrote: > On Sat, 2017-05-06 at 20:00 +0200, Dominick Grift wrote: > > On Sat, May 06, 2017 at 11:07:34AM -0500, Ian Pilcher wrote: > > > On 05/06/2017 12:51 AM, dieter wrote: > > > > Personally, I doubt that you will find a reference. > > > > Instead, I assume that the reference comes from the C runtime > > > > library. > > > > It might hepl optimize memory management to know about "meminfo" > > > > details. > > > > > > You're right. Seems that it's glibc's qsort(). > > > > > > So it seems that any service written in Python (or any other > > > program > > > that uses qsort) needs to be given read access to most of /proc or > > > deal > > > with the (unspecified) consequences of not allowing qsort() to > > > determine > > > the amount of memory in the system. > > > > > > Delightful. > > > > For SELinux policy writers the above is a minor issue compared to > > pythons' shutil.copy2() implementation > > shutil.copy2 behaves like `cp -a` and copies all of the security > > attriutes with the file. > > > > This often causes us to give consumers of shutil.copy2() much broader > > access than strictly needed > > > > This is also a problem with `cp -a` (so python is not alone in this). > > I am not sure how python handles shutil.copy2() but it would be much > > better for us if it would exclude the MAC security attributes when it > > copies > > > > Sort of like shutil.copy2_except_MAC_security_attributes or `cp -a- > > minus-MAC-security-attributes` > > > > Consider this: > > > > some consumer of shutil.copy2 copies /etc/shadow to /tmp/myapp-XXXXX > > and edits it there. > > > > Because it copies the security context with /etc/shadow, it later > > needs to be granted to edit files with the security context for > > shadow files. Effectively forcing us to allow the process to edit > > files with the shadow security context > > > > Whereas if it would have excluded the MAC security contexts when it > > copied the file, we would have just been forced to allow the process > > to read file with the shadow file context, and not to write to it > > > > The above is a little surrealistic example but it is a very common > > issue in general > > > > for example pip3 does this all the time and so pip3 processes need > > much broader access than strictly necessary > > shutil.copy2 behavior wrt SELinux was previously discussed here: > http://selinux.tycho.nsa.narkive.com/euegPAIr/copying-setting-security-selinux-xattr-explicitly > > As a counterexample for your proposal, suppose that shutil.copy2() > defaults to not copying the MAC attributes. Now a process copies > /etc/shadow to /tmp/myapp-XXXXX and edits it there. Since we don't > copy MAC attributes, the file ends up being labeled with whatever type > and range transition is defined for the process on /tmp, or defaults to > that of /tmp. As a result, the /etc/shadow data is now readable under > whatever type/range that happens to be, and potentially leaks to > processes not authorized to read /etc/shadow. > > Given that shutil.copy2 says that it copies metadata, it makes sense to > at least try to copy SELinux attributes. I think the only question is > what to do in case of failure; the earlier thread proposed ignoring > EACCES in the same way it already ignores several other errors. > > Yes that is true, but yes then at least don't fail hard if copying the contexts fails as youve suggested so that we can prevent the ralabel in policy and get away with it -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift
Attachment:
signature.asc
Description: PGP signature
