Your kernel log message said "fs_mgr: Warning crypto footer minor
version 3, expected 0 or 1 or 2 continuing...". This suggests that
you had an encrypted userdata partition created under Android 5.0
(system/vold/cryptfs.h has CURRENT_MINOR_VERSION 3) and you are trying
to boot an older release (e.g. 4.4.4 had CURRENT_MINOR_VERSION 2).
Then it can't decrypt userdata, tries running e2fsck on the userdata
partition, sees it as garbage (because it is encrypted). Not sure
what happens at that point; I'd think that it just wouldn't mount at
all. In any event, this suggests you have corrupted your userdata
partition and thus SELinux is just the messenger, not the source of
the bug.
On Wed, Jan 7, 2015 at 11:49 PM, 심현용 <jonesn5...@gmail.com> wrote:
> And, As you told file-system, I found regard kernel log.
>
> <14>[ 5.948404 / 01-05 07:50:13.479] fs_mgr:
> __mount(source=/dev/block/bootdevice/by-name/system,target=/system,type=ext4)=0
> <11>[ 5.949183 / 01-05 07:50:13.479] fs_mgr: Warning: crypto footer minor
> version 3, expected 0 or 1 or 2 continuing...
> <3>[ 5.949704 / 01-05 07:50:13.479] EXT4-fs (mmcblk0p37): VFS: Can't find
> ext4 filesystem
> <3>[ 5.949716 / 01-05 07:50:13.479] EXT4-fs: Can't find ext4 filesystem
> <3>[ 5.949724 / 01-05 07:50:13.479] EXT4-fs: failed_mount
> <14>[ 5.949832 / 01-05 07:50:13.479] fs_mgr: check_fs():
> mount(/dev/block/bootdevice/by-name/userdata,/data,ext4)=-1
> <14>[ 5.949853 / 01-05 07:50:13.479] fs_mgr: /data temp mount failed
> <14>[ 5.949874 / 01-05 07:50:13.479] fs_mgr: primary superblock of /data
> partition has been crashed. Start Recovery from backup blocks
> <4>[ 5.964026 / 01-05 07:50:13.499] e2fsck_static (265) used greatest
> stack depth: 11928 bytes left
> <14>[ 5.964208 / 01-05 07:50:13.499] e2fsck_static: e2fsck 1.42.9
> (28-Dec-2013)
> <14>[ 5.964263 / 01-05 07:50:13.499] e2fsck_static: /sbin/e2fsck_static:
> Bad magic number in super-block while trying to open
> /dev/block/bootdevice/by-name/userdata
> <14>[ 5.964285 / 01-05 07:50:13.499] e2fsck_static:
> <14>[ 5.964305 / 01-05 07:50:13.499] e2fsck_static: The superblock could
> not be read or does not describe a correct ext2
> <14>[ 5.964323 / 01-05 07:50:13.499] e2fsck_static: filesystem. If the
> device is valid and it really contains an ext2
> <14>[ 5.964341 / 01-05 07:50:13.499] e2fsck_static: filesystem (and not
> swap or ufs or something else), then the superblock
> <14>[ 5.964359 / 01-05 07:50:13.499] e2fsck_static: is corrupt, and you
> might try running e2fsck with an alternate superblock:
> <14>[ 5.964377 / 01-05 07:50:13.499] e2fsck_static: e2fsck -b 8193
> <device>
>
> If it is case, could be changed unlabeled in context?
>
> Thanks.
>
> 2015-01-08 13:23 GMT+09:00 심현용 <jonesn5...@gmail.com>:
>>
>> 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.
