On 09/11/2015 09:01 AM, Florian Zumbiehl wrote: > Hi, > > given that Google seems to have installed clueless tech support drones > operating their "developer bug tracker", I am writing to you in the hope > that someone might be able to help with this, if only by directing me to > some responsible person with traces of clue left - any help would be much > appreciated. > > The problem I am facing is that the SELinux policy in "Android M" seems to > prevent all creation of hardlinks by applications. Now, it just so happens > that hardlinks have been a standard feature of unix-like operating systems > for quite some time, so, unsurprisingly, people have built data structures > using such a standard feature - only to then be told by said tech support > drone that "This is working as intended. Hard linking files is blocked and > an attempt to call link() on a file will return EACCES."[1] > > No, I am not leaving out the justification, there is none given. Yes, I > understand that you can perform certain attacks using (hard)links, but so > you can by adding 42 to the instruction pointer under the right > circumstances, which is not exactly a reason for globally disabling > addition of the number 42 either, and then just telling people "it's > working as intended" when they complain that some additions randomly fail. > The scenario that failed was, while running as user A, linking a file owned > by user A and only writable by user A in a directory owned by user A and > only writable by user A to a second name in that same directory ... which > probably is about as useless for an attack as hardlinks can get? > > Should I just accept that Google will randomly disable well-established and > harmless APIs without warning or documentation and for no reason, or is > there hope to stop this madness? > > Regards, Florian > > [1] https://code.google.com/p/android-developer-preview/issues/detail?id=3150
https://android-review.googlesource.com/#/c/144092 The rationale is given with the neverallow rule in external/sepolicy/untrusted_app.te: # Do not allow untrusted_app to hard link to any files. # In particular, if untrusted_app links to other app data # files, installd will not be able to guarantee the deletion # of the linked to file. Hard links also contribute to security # bugs, so we want to ensure untrusted_app never has this # capability. neverallow untrusted_app file_type:file link; A possible middle ground would be to allow apps to create hard links to app data files (i.e. add "allow untrusted_app app_data_file:file link;", amend the neverallow to "neverallow untrusted_app { file_type -app_data_file }:file link;"), while still preventing them from creating hard links to any other files under /data. That would still permit an app to create hard links to another app's data files however. That could be further restricted by setting /proc/sys/fs/protected_hardlinks to 1 (via init.rc), which should prevent creating such hard links unless the app owns the file or has both read and write to it (also prevents linking to suid/sgid and special files, but those are unlikely in app sandboxes). _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
