I'm running into a related issue on a Galaxy Nexus (maguro) running master +
seandroid.
The denials I'm seeing are coming from sdcardd, not the app.
/mnt/sdcard or equivalent that the app is trying to access and its contents are
properly labeled as u:object_r:sdcard_internal:s0, but /data/media/0 (which
sdcardd is trying to access) and its contents are u:object_r:unlabeled:s0.
/data/media shouldn't be directly accessible from apps but needs to be
accessible by sdcardd.
Does installd.c need to be updated to set a security context when /data/media/0
is created?
type=1400 msg=audit(1375476226.381:87): avc: denied { create } for pid=133
comm="sdcard" name="facebook_ringtone_pop.m4a" scontext=u:r:sdcardd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file
type=1400 msg=audit(1375476226.389:88): avc: denied { getattr } for pid=133
comm="sdcard"
path="/data/media/0/media/audio/notifications/facebook_ringtone_pop.m4a"
dev=mmcblk0p12 ino=447948 scontext=u:r:sdcardd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file
type=1400 msg=audit(1375476226.389:89): avc: denied { write } for pid=141
comm="sdcard" name="facebook_ringtone_pop.m4a" dev=mmcblk0p12 ino=447948
scontext=u:r:sdcardd:s0 tcontext=u:object_r:unlabeled:s0 tclass=file
type=1400 msg=audit(1375476226.389:90): avc: denied { open } for pid=141
comm="sdcard" name="facebook_ringtone_pop.m4a" dev=mmcblk0p12 ino=447948
scontext=u:r:sdcardd:s0 tcontext=u:object_r:unlabeled:s0 tclass=file
shell@maguro:/data/media # ls -Z
drwxrwx--- media_rw media_rw u:object_r:unlabeled:s0 0
drwxrwxr-x media_rw media_rw u:object_r:system_data_file:s0 legacy
drwxrwx--- media_rw media_rw u:object_r:system_data_file:s0 obb
shell@maguro:/data/media/0 # ls -Z
drwxrwxr-x media_rw media_rw u:object_r:unlabeled:s0 Alarms
drwxrwxr-x media_rw media_rw u:object_r:unlabeled:s0 Android
drwxrwxr-x media_rw media_rw u:object_r:unlabeled:s0 DCIM
drwxrwxr-x media_rw media_rw u:object_r:unlabeled:s0 Download
drwxrwxr-x media_rw media_rw u:object_r:unlabeled:s0 Movies
drwxrwxr-x media_rw media_rw u:object_r:unlabeled:s0 Music
drwxrwxr-x media_rw media_rw u:object_r:unlabeled:s0 Notifications
drwxrwxr-x media_rw media_rw u:object_r:unlabeled:s0 Pictures
drwxrwxr-x media_rw media_rw u:object_r:unlabeled:s0 Podcasts
drwxrwxr-x media_rw media_rw u:object_r:unlabeled:s0 Ringtones
drwxrwxr-x media_rw media_rw u:object_r:unlabeled:s0 media
>-----Original Message-----
>From: [email protected] [mailto:owner-seandroid-
>[email protected]] On Behalf Of Stephen Smalley
>Sent: Friday, August 02, 2013 8:51 AM
>To: Janosch Maier
>Cc: rpcraig; [email protected]
>Subject: Re: file_context rules not working
>
>On 08/02/2013 05:35 AM, Janosch Maier wrote:
>> Some more followup for the /data/media issue is needed:
>>
>> The fuse labeling works, i think. The files in /sdcard or /mnt/sdcard
>> look fine:
>> drwxrwxr-x root sdcard_rw u:object_r:sdcard_internal:s0 Alarms
>>
>> But the files in /data/media/0 which is the original location of the
>> files does not:
>> drwxrwxr-x media_rw media_rw u:object_r:unlabeled:s0 Alarms
>>
>> The sdcard service adresses the mounting:
>> # create virtual SD card at /mnt/sdcard, based on the /data/media directory
>> # daemon will drop to user/group system/media_rw after initializing
>> # underlying files in /data/media wil be created with user and group
>> media_rw (1023)
>> service sdcard /system/bin/sdcard /data/media /mnt/shell/emulated 1023
>1023
>> class late_start
>>
>> However, when working on the system, the access to the files is done via
>> /data/media and will fail in enforcinge mode.
>
>On our devices, /data/media is labeled with system_data_file,
>shell@manta/ # cd /data/media
>shell@manta:/data/media # ls -Z
>drwxrwx--- media_rw media_rw u:object_r:system_data_file:s0 0
>drwxrwxr-x media_rw media_rw u:object_r:system_data_file:s0 legacy
>drwxrwx--- media_rw media_rw u:object_r:system_data_file:s0 obb
>
>While /data/media provides the underlying storage, I don't believe it
>should be accessible in the same way as the fuse mount. Note that the
>DAC ownerships and modes are different as well. Thus we don't want the
>same type on it.
>
>I think if you use the correct APIs for accessing external storage, then
>you will go through the fuse mount interface and thus not have any
>problems with permissions.
>
>
>
>
>
>--
>This message was distributed to subscribers of the seandroid-list mailing list.
>If you no longer wish to subscribe, send mail to [email protected]
>with
>the words "unsubscribe seandroid-list" without quotes as the message.
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.
