[prev in list] [next in list] [prev in thread] [next in thread]
List: seandroid-list
Subject: Re: I have some question about restorcon_recursive's skipped because of symbolic-link attribute.
From: 심현용 <jonesn5508 () gmail ! com>
Date: 2015-08-26 6:25:10
Message-ID: CA+zkWNVqXkCZKcganr8b44ndd16N5VBx+tAmqhDZBGRUWwHwjQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thank you for you detail guide.
It is not symlink's restorecon_recursive issue, it is MountService's issue.
I knew, It doesn't work package scan in sdcard when is upgrading L to M.
In this reason, this package doesn't come in PMS's restoreconData.
Thanks, Regard.
2015-08-25 23:57 GMT+09:00 Stephen Smalley <sds@tycho.nsa.gov>:
> Ok, I think I figured it out. A few points:
>
> - It looks like we haven't been setting the lib symlink context to match
> the rest of the app data directory for some time. We did that
> originally but it looks like it got dropped at some point (before the
> relocation of installd to frameworks/native). Not clear that is a
> problem though since those symlinks are also owned by installd rather
> than by the app UID, so it isn't necessarily the case that you want them
> to be accessible beyond read/follow.
>
> - installd now creates the symlinks in response to a separate command
> (linklib) issued by the frameworks rather than upon install or
> make_user_data commands. If we wanted them to be labeled with the same
> level as the rest of the directory, we would need to add a
> selinux_android_restorecon() call there.
>
> - The symlinks are root-owned in master because installd has reverted to
> running as root in master, whereas they used to be install-owned.
>
> So I don't believe there is any problem with restorecon (restorecon -DRv
> /data/data/<pkgdir> labels the symlinks correctly for me), but merely
> with the fact that installd is creating the symlinks and is not
> explicitly labeling them. So they inherit the type from the parent
> directory (the usual default) but inherit their level from the creating
> process (also the usual default).
>
> The question is whether this is in fact a problem in any way. As I
> said, the symlinks should still be readable by the apps, so the only
> impact is that the apps won't be allowed to unlink the symlinks. But I
> don't see why that would be a problem. It is arguable that the symlinks
> shouldn't be unlinkable by the apps in the first place. Is this
> labeling causing you any real problems with M or are you simply noticing
> it as an inconsistency?
>
> On 08/24/2015 07:55 PM, 심현용 wrote:
> > Dear Stephan.
> >
> > Thank you for your kindly reply.
> >
> > Actually, this issue doen't using about forward-locked app.
> > As you guessing, It should be work likes vold deamon's move to SDcard in
> > Setting apk.
> >
> > "Move to sdcard" operation is that apk's user datas likes libs.. can
> > move to asec partition(sdcard).
> >
> > It is possible to occur doessn't perform restorecon of the symlink?
> >
> > I'm very curious about PMS operation during L to M upgrade.
> > As you said that installd handles the restorecon of package directories
> > on upgrade, I think it is also called api
> > selinux_android_restorecon_common in android.c
> >
> > I did logging in selinux_android_restorecon_common's default : (before
> > restorecon_sb) like that.
> >
> > default:
> > if ( strstr(pathname, "nhn") != NULL )
> > selinux_log(SELINUX_ERROR, "hyunyong.sim : default in
> > path : %s\n", pathname);
> >
> > I couldn't find /data/data/ package log.
> >
> > but when I didn't operation move to sdcard in Setting apk,
> > I could find /data/app/(package name) in
> > selinux_android_restorecon_common like bellow.
> >
> > init: hyunyong.sim : restorecon_sb path name
> > /data/app/com.nhn.android.search-1.
> > init: hyunyong.sim : restorecon_sb path name
> > /data/app/com.nhn.android.search-1/base.apk.
> > init: hyunyong.sim : restorecon_sb path name
> > /data/app/com.nhn.android.search-1/lib.
> > init: hyunyong.sim : restorecon_sb path name
> > /data/app/com.nhn.android.search-1/lib/arm.
> > init: hyunyong.sim : restorecon_sb path name
> > /data/app/com.nhn.android.search-1/lib/arm/libafpe2.so.
> > init: hyunyong.sim : restorecon_sb path name
> > /data/app/com.nhn.android.search-1/lib/arm/libCrashHandler.so.
> > init: hyunyong.sim : restorecon_sb path name
> > /data/app/com.nhn.android.search-1/lib/arm/libSpeechRecogJNI2.so.
> >
> > It is possible to restorecon_recursive(/data/data) ?
> >
> > I don't know where can I debugging in my source.
> >
> > Please give me a hands.
> >
> > Thanks.
> >
> > 2015-08-25 3:49 GMT+09:00 Stephen Smalley <sds@tycho.nsa.gov
> > <mailto:sds@tycho.nsa.gov>>:
> >
> > On 08/23/2015 09:29 PM, 심현용 wrote:
> > > Dear all.
> > >
> > > At the booting time, I know restorecon_recursive about /data in
> init.rc
> > > or restsorecon_recursive(/sys) in init.cpp.
> > >
> > > /system/core/rootdir/init.rc
> > > 369 # Set SELinux security contexts on upgrade or policy
> update.
> > > 370 restorecon_recursive /data
> > >
> > > /system/core/init/init.cpp
> > > 1208 restorecon_recursive("/sys");
> > >
> > > But, it doesn't work well likes bellow file attribute like
> symbolic-link.
> > >
> > > /data/data/com.nhn.android.search # ls -Z
> > > lrwxrwxrwx install install
> > *u:object_r:app_data_file:s0* *lib
> > > -> /mnt/asec/com.nhn.android.search-2/lib/arm*/
> > >
> > > When upgrading processing L to M OS, this label
> (/data/data/"pakcage")
> > > has to change app_data_file:s0:c512,c768, but didn't work about
> symbolic
> > > link attribute file.
> > >
> > > When I execute command restorecon
> /data/data/com.nhn.android.search in
> > > adb shell.
> > > It did well like bellow.
> > > drwxr-x--x u0_a184 u0_a184
> > > u:object_r:app_data_file:s0:c512,c768 com.nhn.android.search
> > >
> > > How can I resolve this issue.
> >
> > That does appear to be a bug. It is actually installd that handles
> the
> > restorecon of package directories on upgrade, triggered by calls from
> > the PMS. I reproduced by doing an adb install -l of an apk on L,
> then
> > upgrading to master. As you note above, the lib symlink is not
> > relabeled in that situation. If you run restorecon -RDv on the
> package
> > directory from an adb shell, it is then correctly relabeled. This
> only
> > appears to occur with forward-locked apps; regular apps have their
> lib
> > symlink correctly relabeled with categories. The other interesting
> > difference in symlinks is that the forward-locked apps have
> root-owned
> > symlinks while the regular apps have install-owned ones.
> >
> > I'm not sure of the impact however. In either case, the symlink
> should
> > be readable by the app, so following the link should work regardless.
> > The app won't be able to unlink the symlink in the forward-locked app
> > case due to this mislabeling, but I don't know why it would want to
> > do so.
> >
> > I'm guessing that these symlinks are actually created by something
> other
> > than installd when the asec container is mounted (vold?), and that
> > component doesn't perform a restorecon of the symlink.
> >
> >
>
>
[Attachment #5 (text/html)]
<div dir="ltr">Thank you for you detail guide.<div><br></div><div>It is not \
symlink's restorecon_recursive issue, it is MountService's issue.</div><div>I \
knew, It doesn't work package scan in sdcard when is upgrading L to \
M.</div><div><br></div><div>In this reason, this package doesn't come in \
PMS's restoreconData.</div><div><br></div><div>Thanks, Regard.</div></div><div \
class="gmail_extra"><br><div class="gmail_quote">2015-08-25 23:57 GMT+09:00 Stephen \
Smalley <span dir="ltr"><<a href="mailto:sds@tycho.nsa.gov" \
target="_blank">sds@tycho.nsa.gov</a>></span>:<br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, I think I \
figured it out. A few points:<br> <br>
- It looks like we haven't been setting the lib symlink context to match<br>
the rest of the app data directory for some time. We did that<br>
originally but it looks like it got dropped at some point (before the<br>
relocation of installd to frameworks/native). Not clear that is a<br>
problem though since those symlinks are also owned by installd rather<br>
than by the app UID, so it isn't necessarily the case that you want them<br>
to be accessible beyond read/follow.<br>
<br>
- installd now creates the symlinks in response to a separate command<br>
(linklib) issued by the frameworks rather than upon install or<br>
make_user_data commands. If we wanted them to be labeled with the same<br>
level as the rest of the directory, we would need to add a<br>
selinux_android_restorecon() call there.<br>
<br>
- The symlinks are root-owned in master because installd has reverted to<br>
running as root in master, whereas they used to be install-owned.<br>
<br>
So I don't believe there is any problem with restorecon (restorecon -DRv<br>
/data/data/<pkgdir> labels the symlinks correctly for me), but merely<br>
with the fact that installd is creating the symlinks and is not<br>
explicitly labeling them. So they inherit the type from the parent<br>
directory (the usual default) but inherit their level from the creating<br>
process (also the usual default).<br>
<br>
The question is whether this is in fact a problem in any way. As I<br>
said, the symlinks should still be readable by the apps, so the only<br>
impact is that the apps won't be allowed to unlink the symlinks. But I<br>
don't see why that would be a problem. It is arguable that the symlinks<br>
shouldn't be unlinkable by the apps in the first place. Is this<br>
labeling causing you any real problems with M or are you simply noticing<br>
it as an inconsistency?<br>
<div><div class="h5"><br>
On 08/24/2015 07:55 PM, 심현용 wrote:<br>
> Dear Stephan.<br>
><br>
> Thank you for your kindly reply.<br>
><br>
> Actually, this issue doen't using about forward-locked app.<br>
> As you guessing, It should be work likes vold deamon's move to SDcard in<br>
> Setting apk.<br>
><br>
> "Move to sdcard" operation is that apk's user datas likes libs.. \
can<br> > move to asec partition(sdcard).<br>
><br>
> It is possible to occur doessn't perform restorecon of the symlink?<br>
><br>
> I'm very curious about PMS operation during L to M upgrade.<br>
> As you said that installd handles the restorecon of package directories<br>
> on upgrade, I think it is also called api<br>
> selinux_android_restorecon_common in android.c<br>
><br>
> I did logging in selinux_android_restorecon_common's default : (before<br>
> restorecon_sb) like that.<br>
><br>
> default:<br>
> if ( strstr(pathname, "nhn") != NULL )<br>
> selinux_log(SELINUX_ERROR, "hyunyong.sim : default \
in<br> > path : %s\n", pathname);<br>
><br>
> I couldn't find /data/data/ package log.<br>
><br>
> but when I didn't operation move to sdcard in Setting apk,<br>
> I could find /data/app/(package name) in<br>
> selinux_android_restorecon_common like bellow.<br>
><br>
> init: hyunyong.sim : restorecon_sb path name<br>
> /data/app/com.nhn.android.search-1.<br>
> init: hyunyong.sim : restorecon_sb path name<br>
> /data/app/com.nhn.android.search-1/base.apk.<br>
> init: hyunyong.sim : restorecon_sb path name<br>
> /data/app/com.nhn.android.search-1/lib.<br>
> init: hyunyong.sim : restorecon_sb path name<br>
> /data/app/com.nhn.android.search-1/lib/arm.<br>
> init: hyunyong.sim : restorecon_sb path name<br>
> /data/app/com.nhn.android.search-1/lib/arm/libafpe2.so.<br>
> init: hyunyong.sim : restorecon_sb path name<br>
> /data/app/com.nhn.android.search-1/lib/arm/libCrashHandler.so.<br>
> init: hyunyong.sim : restorecon_sb path name<br>
> /data/app/com.nhn.android.search-1/lib/arm/libSpeechRecogJNI2.so.<br>
><br>
> It is possible to restorecon_recursive(/data/data) ?<br>
><br>
> I don't know where can I debugging in my source.<br>
><br>
> Please give me a hands.<br>
><br>
> Thanks.<br>
><br>
> 2015-08-25 3:49 GMT+09:00 Stephen Smalley <<a \
href="mailto:sds@tycho.nsa.gov">sds@tycho.nsa.gov</a><br> </div></div>> \
<mailto:<a href="mailto:sds@tycho.nsa.gov">sds@tycho.nsa.gov</a>>>:<br> <div \
class="HOEnZb"><div class="h5">><br> > On 08/23/2015 09:29 PM, 심현용 \
wrote:<br> > > Dear all.<br>
> ><br>
> > At the booting time, I know restorecon_recursive about /data in \
init.rc<br> > > or restsorecon_recursive(/sys) in init.cpp.<br>
> ><br>
> > /system/core/rootdir/init.rc<br>
> > 369 # Set SELinux security contexts on upgrade or policy \
update.<br> > > 370 restorecon_recursive /data<br>
> ><br>
> > /system/core/init/init.cpp<br>
> > 1208 restorecon_recursive("/sys");<br>
> ><br>
> > But, it doesn't work well likes bellow file attribute like \
symbolic-link.<br> > ><br>
> > /data/data/com.nhn.android.search # ls -Z<br>
> > lrwxrwxrwx install install<br>
> *u:object_r:app_data_file:s0* *lib<br>
> > -> /mnt/asec/com.nhn.android.search-2/lib/arm*/<br>
> ><br>
> > When upgrading processing L to M OS, this label \
(/data/data/"pakcage")<br> > > has to change \
app_data_file:s0:c512,c768, but didn't work about symbolic<br> > > \
link attribute file.<br> > ><br>
> > When I execute command restorecon /data/data/com.nhn.android.search \
in<br> > > adb shell.<br>
> > It did well like bellow.<br>
> > drwxr-x--x u0_a184 u0_a184<br>
> > u:object_r:app_data_file:s0:c512,c768 com.nhn.android.search<br>
> ><br>
> > How can I resolve this issue.<br>
><br>
> That does appear to be a bug. It is actually installd that handles \
the<br> > restorecon of package directories on upgrade, triggered by calls \
from<br> > the PMS. I reproduced by doing an adb install -l of an apk on \
L, then<br> > upgrading to master. As you note above, the lib symlink is \
not<br> > relabeled in that situation. If you run restorecon -RDv on the \
package<br> > directory from an adb shell, it is then correctly relabeled. \
This only<br> > appears to occur with forward-locked apps; regular apps \
have their lib<br> > symlink correctly relabeled with categories. The \
other interesting<br> > difference in symlinks is that the forward-locked \
apps have root-owned<br> > symlinks while the regular apps have \
install-owned ones.<br> ><br>
> I'm not sure of the impact however. In either case, the symlink \
should<br> > be readable by the app, so following the link should work \
regardless.<br> > The app won't be able to unlink the symlink in the \
forward-locked app<br> > case due to this mislabeling, but I don't know \
why it would want to<br> > do so.<br>
><br>
> I'm guessing that these symlinks are actually created by something \
other<br> > than installd when the asec container is mounted (vold?), and \
that<br> > component doesn't perform a restorecon of the symlink.<br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>
_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Seandroid-list-request@tycho.nsa.gov.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic