Hi,
> 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.
What's the point of this? And can you at all?
I mean, if it's just about reclaiming user IDs, I guess you might as well
donate the files to a nobody user before unlinking (and adjust the
permissions accordingly, etc.). If it's about reclaiming the storage: Why
would you? Especially so given that there might still be open file
descriptors that would prevent the storage from being reclaimed anyway.
> # 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;
Yeah, let's forbid adding 42, too, then! Brilliant!
> 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.
I can't really judge whether that's a good idea or not, but if an
application could create hardlinks between files in its own data directory
hierarchy, that certainly would sound a lot saner than the current
situation.
> 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).
That sounds reasonable to me.
BTW, has anyone investigated how this prohibition on link() interacts with
open(O_TMPFILE)/linkat(AT_EMPTY_PATH)?
Regards, Florian
_______________________________________________
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.
