Please, keep the list cc'd on these discussions. I have restored the
cc line above.
If the file was created while booting a custom boot or recovery image
that had SELinux disabled, then files could be created that are
completely missing security.selinux attributes and thus be unlabeled.
Or if you had a buggy or corrupted OTA updater script or
/file_contexts file, then you could end up putting an invalid security
context on a file that would then be remapped to unlabeled.
On Wed, Jan 7, 2015 at 11:23 PM, 심현용 <jonesn5...@gmail.com> wrote:
> Thank you for your reply.
>
> I don't know exactly how this file(librctransport.so) create, It probably
> anyone apk made them.
> but I can found in my target.
>
> It is located in /data/data/com.uei.lg.quicksetsdk.lite/files, and when
> normal boot, it is app_data_file
> -rw------- u0_a101 u0_a101 u:object_r:app_data_file:s0
> librctransport.so
>
> But, when this issue occurred (it is 1 times issue) , I can also see another
> unlabeled denials after read strings.
>
> <6>[ 55.830859 / 01-03 23:52:26.688] read descriptors
> <6>[ 55.830941 / 01-03 23:52:26.688] read strings
> <14>[ 56.313405 / 01-03 23:52:27.168] type=1400 audit(1420296747.168:5):
> avc: denied { getattr } for pid=1733 comm="m.android.phone"
> path="/data/data/com.android.providers.telephony/databases/HbpcdLookup.db-journal"
> dev="dm-0" ino=577530 scontext=u:r:radio:s0 tcontext=u:object_r:unlabeled:s0
> tclass=file permissive=0
> <14>[ 56.330076 / 01-03 23:52:27.188] type=1400 audit(1420296747.168:6):
> avc: denied { read } for pid=1733 comm="m.android.phone"
> name="HbpcdLookup.db-journal" dev="dm-0" ino=577530 scontext=u:r:radio:s0
> tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
> <14>[ 56.330493 / 01-03 23:52:27.188] type=1400 audit(1420296747.168:7):
> avc: denied { getattr } for pid=1733 comm="m.android.phone"
> path="/data/data/com.android.providers.telephony/databases/HbpcdLookup.db-journal"
> dev="dm-0" ino=577530 scontext=u:r:radio:s0 tcontext=u:object_r:unlabeled:s0
> tclass=file permissive=0
> <14>[ 56.330791 / 01-03 23:52:27.188] type=1400 audit(1420296747.168:8):
> avc: denied { getattr } for pid=1733 comm="m.android.phone"
> path="/data/data/com.android.providers.telephony/databases/HbpcdLookup.db-journal"
> dev="dm-0" ino=577530 scontext=u:r:radio:s0 tcontext=u:object_r:unlabeled:s0
> tclass=file permissive=0
> <14>[ 56.331039 / 01-03 23:52:27.188] type=1400 audit(1420296747.168:9):
> avc: denied { getattr } for pid=1733 comm="m.android.phone"
> path="/data/data/com.android.providers.telephony/databases/HbpcdLookup.db-journal"
> dev="dm-0" ino=577530 scontext=u:r:radio:s0 tcontext=u:object_r:unlabeled:s0
> tclass=file permissive=0
> <14>[ 56.331257 / 01-03 23:52:27.188] type=1400 audit(1420296747.168:10):
> avc: denied { read write } for pid=1733 comm="m.android.phone"
> name="HbpcdLookup.db-journal" dev="dm-0" ino=577530 scontext=u:r:radio:s0
> tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
> <14>[ 56.331453 / 01-03 23:52:27.188] type=1400 audit(1420296747.168:11):
> avc: denied { read } for pid=1733 comm="m.android.phone"
> name="HbpcdLookup.db-journal" dev="dm-0" ino=577530 scontext=u:r:radio:s0
> tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
> <14>[ 56.331640 / 01-03 23:52:27.188] type=1400 audit(1420296747.168:12):
> avc: denied { getattr } for pid=1733 comm="m.android.phone"
> path="/data/data/com.android.providers.telephony/databases/HbpcdLookup.db-journal"
> dev="dm-0" ino=577530 scontext=u:r:radio:s0 tcontext=u:object_r:unlabeled:s0
> tclass=file permissive=0
> <14>[ 56.331837 / 01-03 23:52:27.188] type=1400 audit(1420296747.168:13):
> avc: denied { getattr } for pid=1733 comm="m.android.phone"
> path="/data/data/com.android.providers.telephony/databases/HbpcdLookup.db-journal"
> dev="dm-0" ino=577530 scontext=u:r:radio:s0 tcontext=u:object_r:unlabeled:s0
> tclass=file permissive=0
> <14>[ 56.394298 / 01-03 23:52:27.258] type=1400 audit(1420296747.248:14):
> avc: denied { getattr } for pid=1733 comm="m.android.phone"
> path="/data/data/com.android.providers.telephony/databases/HbpcdLookup.db-journal"
> dev="dm-0" ino=577530 scontext=u:r:radio:s0 tcontext=u:object_r:unlabeled:s0
> tclass=file permissive=0
> <14>[ 56.397720 / 01-03 23:52:27.258] type=1400 audit(1420296747.258:15):
> avc: denied { read } for pid=1733 comm="m.android.phone"
> name="HbpcdLookup.db-journal" dev="dm-0" ino=577530 scontext=u:r:radio:s0
> tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
> <14>[ 56.398034 / 01-03 23:52:27.258] type=1400 audit(1420296747.258:16):
> avc: denied { getattr } for pid=1733 comm="m.android.phone"
> path="/data/data/com.android.providers.telephony/databases/HbpcdLookup.db-journal"
> dev="dm-0" ino=577530 scontext=u:r:radio:s0 tcontext=u:object_r:unlabeled:s0
> tclass=file permissive=0
>
>
> In these case, can I understand memory corruption?
> I always thank to your kind.
>
>
> 2015-01-08 11:05 GMT+09:00 Stephen Smalley <stephen.smal...@gmail.com>:
>>
>> BTW, your kernel log messages were normal and do not indicate any kind
>> of memory corruption by themselves. What you are seeing could be
>> completely normal if your file_contexts file has a truncated entry
>> with u:ob rather than a complete security context or if your OTA
>> updater script has a buggy line that sets the context to u:ob. Then
>> the file would be labeled on the filesystem with that attribute value
>> and SELinux is just correctly remapping it to unlabeled.
>>
>> On Wed, Jan 7, 2015 at 8:51 PM, Stephen Smalley
>> <stephen.smal...@gmail.com> wrote:
>> > You dropped the list from the cc on your reply.
>> > I do not understand your reply. apk_data_file would be for files
>> > created under /data/app. Where is this library file located? Was it
>> > part of the original filesystem image that was flashed to the device
>> > or created while running the regular Android boot or created from
>> > recovery (e.g. for an OTA)?
>> > Kernel memory corruption can occur due to kernel bugs, but any
>> > memory-related bug in the kernel can affect any part of the kernel, so
>> > e.g. a bug in a filesystem driver can corrupt SELinux's memory since
>> > there is no separation within the kernel. But before we assume kernel
>> > memory corruption, let's rule out a userspace cause first. Which
>> > brings me back to the question of how this file was created.
>> >
>> > On Wed, Jan 7, 2015 at 8:26 PM, 심현용 <jonesn5...@gmail.com> wrote:
>> >> Thanks for reply quickly.
>> >>
>> >> librctransport.so's contexts is apk_data_file. It will be create
>> >> someone
>> >> apk.
>> >>
>> >> As you told me, I found bellow kernel log before initialize SELinux.
>> >>
>> >> <6>[ 0.000000 / 01-01 00:00:00.000] kmemleak: Kernel memory leak
>> >> detector
>> >> disabled
>> >> <6>[ 0.000000 / 01-01 00:00:00.000] Architected cp15 and mmio
>> >> timer(s)
>> >> running at 19.20MHz (virt/virt).
>> >> <6>[ 0.000000 / 01-01 00:00:00.000] sched_clock: 56 bits at 19MHz,
>> >> resolution 52ns, wraps every 3579139424256ns
>> >> <6>[ 0.000353 / 01-01 00:00:00.000] Calibrating delay loop
>> >> (skipped),
>> >> value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000)
>> >> <6>[ 0.000371 / 01-01 00:00:00.000] pid_max: default: 32768 minimum:
>> >> 301
>> >> <6>[ 0.000938 / 01-01 00:00:00.000] Security Framework initialized
>> >> <6>[ 0.000978 / 01-01 00:00:00.000] SELinux: Initializing.
>> >> <7>[ 0.001117 / 01-01 00:00:00.000] SELinux: Starting in permissive
>> >> mode
>> >>
>> >> Is it possible to corrupt kernel memory?
>> >>
>> >> Thank you for your kinds.
>> >>
>> >> 2015-01-08 8:58 GMT+09:00 Stephen Smalley <stephen.smal...@gmail.com>:
>> >>>
>> >>> How was this librctransport.so file installed? What set its security
>> >>> context?
>> >>> Unless there was kernel memory corruption (which could be from any
>> >>> source, not just SELinux), the message indicates that the
>> >>> security.selinux attribute on that file was set to u:ob (e.g. when the
>> >>> filesystem image was created or by the recovery console) and therefore
>> >>> is invalid. SELinux then treats it as if it had the unlabeled
>> >>> context. So no bug in SELinux here, but rather in whatever set that
>> >>> security context on that file.
>> >>>
>> >>> On Wed, Jan 7, 2015 at 6:33 PM, 심현용 <jonesn5...@gmail.com> wrote:
>> >>> > Dear Stephen.
>> >>> >
>> >>> > Hi , I'm a developer in Korea.
>> >>> > I have some question bellow issue.
>> >>> >
>> >>> > - This is kernel log
>> >>> > <6>[ 65.302303 / 01-03 23:57:09.194] SELinux: Context u:ob is not
>> >>> > valid
>> >>> > (left unmapped).
>> >>> > <14>[ 65.303044 / 01-03 23:57:09.194] type=1400
>> >>> > audit(1420297029.194:18):
>> >>> > avc: denied { write } for pid=2511 comm="uicksetsdk.lite"
>> >>> > name="librctransport.so" dev="dm-0" ino=577578
>> >>> > scontext=u:r:platform_app:s0
>> >>> > tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
>> >>> > <14>[ 65.603044 / 01-03 23:57:09.494] type=1400
>> >>> > audit(1420297029.494:19):
>> >>> > avc: denied { read } for pid=2511 comm="uicksetsdk.lite"
>> >>> > name="librctransport.so" dev="dm-0" ino=577578
>> >>> > scontext=u:r:platform_app:s0
>> >>> > tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
>> >>> >
>> >>> > It is reason that left unmmaped is occurred unlabeled issue.
>> >>> >
>> >>> > I think it is parsing error.
>> >>> > Originally, Context It has to display like u:object_r:contexts:s0
>> >>> > but it
>> >>> > split like that Context u:ob!
>> >>> >
>> >>> > I think this is related kernel source.
>> >>> >
>> >>> > kernel/security/selinux/ss/sidtab.c
>> >>> >
>> >>> > int sidtab_context_to_sid(struct sidtab *s,
>> >>> > struct context *context,
>> >>> > u32 *out_sid)
>> >>> > {
>> >>> > u32 sid;
>> >>> > int ret = 0;
>> >>> > unsigned long flags;
>> >>> >
>> >>> > *out_sid = SECSID_NULL;
>> >>> >
>> >>> > sid = sidtab_search_cache(s, context);
>> >>> > if (!sid)
>> >>> > sid = sidtab_search_context(s, context);
>> >>> > if (!sid) {
>> >>> > spin_lock_irqsave(&s->lock, flags);
>> >>> > /* Rescan now that we hold the lock. */
>> >>> > sid = sidtab_search_context(s, context);
>> >>> > if (sid)
>> >>> > goto unlock_out;
>> >>> > /* No SID exists for the context. Allocate a new one. */
>> >>> > if (s->next_sid == UINT_MAX || s->shutdown) {
>> >>> > ret = -ENOMEM;
>> >>> > goto unlock_out;
>> >>> > }
>> >>> > sid = s->next_sid++;
>> >>> > if (context->len)
>> >>> > printk(KERN_INFO
>> >>> > "SELinux: Context %s is not valid (left
>> >>> > unmapped).\n",
>> >>> > context->str);
>> >>> > ret = sidtab_insert(s, sid, context);
>> >>> >
>> >>> > Do you know why this problem occurring?
>> >>> > And, how to solve this issue?
>> >>> >
>> >>> > Please, give me a hand.
>> >>> >
>> >>> > Thanks.
>> >>> >
>> >>> > _______________________________________________
>> >>> > 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.
>> >>
>> >>
>
>
_______________________________________________
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.
