I am looking to contribute to Android security and at the same time
write my thesis.
I have experience in C++ programming as well as other languages; and
also in coporate security management.
Anyone who can come up with a good way of addressing this security
challenge operationally will be doing a lot of Android users a
significant favor. The Android team believes this is unnecessary to
address, so it's up to the community to come up with some way of
avoiding the impact of this (IMHO flawed) architecture.
Regards,
Juan Felipe
On Aug 2, 2:08 pm, Luis <lmgu...@hotmail.com> wrote:
> I am looking to contribute to Android security and at the same time
> write my thesis.
> I have experience in C++ programming as well as other languages; and
> also in coporate security management.
Fixing the architecture is not particularly realistic IMO except as a *possible* solution because Google would unlikely accept code just like that. IMHO, such an effort requires Google support from the beginning since this is *core* Android.
> Anyone who can come up with a good way of addressing this security > challenge operationally will be doing a lot of Android users a > significant favor. The Android team believes this is unnecessary to > address, so it's up to the community to come up with some way of > avoiding the impact of this (IMHO flawed) architecture.
> Regards,
> Juan Felipe
> On Aug 2, 2:08 pm, Luis <lmgu...@hotmail.com> wrote: >> Hi all,
>> I am looking to contribute to Android security and at the same time >> write my thesis. >> I have experience in C++ programming as well as other languages; and >> also in coporate security management.
For the second one (CA-signed certificates), I can say it is fairly unlikely we would want to accept something like that in to the platform; it is completely contrary to the open model of Android.
For the first, research on identifying conflation of permissions that are of interest to the user would certainly be interesting. For any one going down this road, keep in mind that the most important thing is how to present this kind of stuff to the user in a meaningful way.
> Anyone who can come up with a good way of addressing this security > challenge operationally will be doing a lot of Android users a > significant favor. The Android team believes this is unnecessary to > address, so it's up to the community to come up with some way of > avoiding the impact of this (IMHO flawed) architecture.
> Regards,
> Juan Felipe
> On Aug 2, 2:08 pm, Luis <lmgu...@hotmail.com> wrote: > > Hi all,
> > I am looking to contribute to Android security and at the same time > > write my thesis. > > I have experience in C++ programming as well as other languages; and > > also in coporate security management.
Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
You might look into a suitable way of securing data on the SDcard. It's a FAT file system, so you can't use UNIX permissions to restrict applications. Officially, nothing sensitive is supposed to be placed on the SDcard. However, there are some situations (at least in my research) where it would be nice to show through some sort of analysis that two applications truly are isolated and can't share data, even through the SDcard.
The difficulty is that the SDcard needs to be FAT, because the PC mounts it. I read on one of the Android mailing lists a while back that there is a desire not to make kernel modifications to support such isolation. That may, or may not, be a requirement for you.
This leaves the question of how to add security to the SDcard in such a way that it still allows the user to access all of the files when mounted on a PC.
I've tried to get some Masters students here at Penn State to look at the problem, but no one bit (yet). It's not a particularly deep research problem, but it's something I'd like to see a good solution for. Part of your evaluation should look at how existing applications use the SDcard and whether or not your solution breaks these applications. Theoretically, Content Providers should be used, but this might not always be the case.
> I am looking to contribute to Android security and at the same time > write my thesis. > I have experience in C++ programming as well as other languages; and > also in coporate security management.
Hi, Basically is to create a partition which supports a stronger enabled FS. The 2 options I know of are : virtual disk via device mapper and real partition (FAT & EXT3)
More elaboration on the methods: It is possible to have a virtual drive on the FAT, namely, you have one file on the FAT and that found is mounted (via device mapper) as a file system, meaning that you can have full yaffs2 or any other type of supported FS by the kerne. If you will use encrypted FS(dm-crypt), it will protected the visibility of file when mounted onto PC. You need to make sure that the kernel supports device mapper, and make sure that on the initial mounting table the new partition appears. A different method could be 2 partitions, one is FAT and the other any FS you want that the linux supports. For this method you can use simple tools such as gparted to do that.
On Mon, Aug 3, 2009 at 11:24 PM, William Enck <e...@cse.psu.edu> wrote:
> Luis,
> You might look into a suitable way of securing data on the SDcard. It's a > FAT file system, so you can't use UNIX permissions to restrict applications. > Officially, nothing sensitive is supposed to be placed on the SDcard. > However, there are some situations (at least in my research) where it would > be nice to show through some sort of analysis that two applications truly > are isolated and can't share data, even through the SDcard.
> The difficulty is that the SDcard needs to be FAT, because the PC mounts > it. I read on one of the Android mailing lists a while back that there is a > desire not to make kernel modifications to support such isolation. That may, > or may not, be a requirement for you.
> This leaves the question of how to add security to the SDcard in such a way > that it still allows the user to access all of the files when mounted on a > PC.
> I've tried to get some Masters students here at Penn State to look at the > problem, but no one bit (yet). It's not a particularly deep research > problem, but it's something I'd like to see a good solution for. Part of > your evaluation should look at how existing applications use the SDcard and > whether or not your solution breaks these applications. Theoretically, > Content Providers should be used, but this might not always be the case.
> Best,
> -Will
> Luis wrote:
>> Hi all,
>> I am looking to contribute to Android security and at the same time >> write my thesis. >> I have experience in C++ programming as well as other languages; and >> also in coporate security management.
I think my requirements were a little muddled when I was describing the security mechanism I'm looking for. I'm not trying to create secure storage on the SDcard. Rather, I'm looking for one file system that is accessed by both Android applications and the PC, but still isolates Android applications. That is, if AppA writes FileA, the default permissions keep AppB from access it. However, when the phone is mounted on a PC, the user can access FileA.
Correct me if I'm wrong, but I don't think any of your solution provide that functionality.
Moses Roses wrote: > Hi, > Basically is to create a partition which supports a stronger enabled FS. > The 2 options I know of are : virtual disk via device mapper and real > partition (FAT & EXT3)
> More elaboration on the methods: > It is possible to have a virtual drive on the FAT, namely, you have one > file on the FAT and that found is mounted (via device mapper) as a file > system, meaning that you can have full yaffs2 or any other type of > supported FS by the kerne. If you will use encrypted FS(dm-crypt), it > will protected the visibility of file when mounted onto PC. > You need to make sure that the kernel supports device mapper, and make > sure that on the initial mounting table the new partition appears. > A different method could be 2 partitions, one is FAT and the other any > FS you want that the linux supports. For this method you can use simple > tools such as gparted to do that.
> Good Luck, > Moses
> On Mon, Aug 3, 2009 at 11:24 PM, William Enck <e...@cse.psu.edu > <mailto:e...@cse.psu.edu>> wrote:
> Luis,
> You might look into a suitable way of securing data on the SDcard. > It's a FAT file system, so you can't use UNIX permissions to > restrict applications. Officially, nothing sensitive is supposed to > be placed on the SDcard. However, there are some situations (at > least in my research) where it would be nice to show through some > sort of analysis that two applications truly are isolated and can't > share data, even through the SDcard.
> The difficulty is that the SDcard needs to be FAT, because the PC > mounts it. I read on one of the Android mailing lists a while back > that there is a desire not to make kernel modifications to support > such isolation. That may, or may not, be a requirement for you.
> This leaves the question of how to add security to the SDcard in > such a way that it still allows the user to access all of the files > when mounted on a PC.
> I've tried to get some Masters students here at Penn State to look > at the problem, but no one bit (yet). It's not a particularly deep > research problem, but it's something I'd like to see a good solution > for. Part of your evaluation should look at how existing > applications use the SDcard and whether or not your solution breaks > these applications. Theoretically, Content Providers should be used, > but this might not always be the case.
> Best,
> -Will
> Luis wrote:
> Hi all,
> I am looking to contribute to Android security and at the same time > write my thesis. > I have experience in C++ programming as well as other languages; and > also in coporate security management.
Will, The encryption is just an additional capability you can have once you have a virtual partition. As for having ext2/3 FS on microSD, well, you can use many freeware addons for windows that can read it.
Or...use a Samba server on Android to access the partition as a "shared directory". This way internally you have a FS which supports all the permissions needed for isolation just as in internal memory, and a server which provides good interoperability between linux-like platform to a windows PC. The server gives another control mechanism for what you want to expose to the PC (which is even better than the current situation).
If you want to read the MicroSD directly via a card reader - you will need the addon freewares (just google a bit).
On Thu, Aug 6, 2009 at 2:44 AM, William Enck <e...@cse.psu.edu> wrote:
> Moses,
> I think my requirements were a little muddled when I was describing the > security mechanism I'm looking for. I'm not trying to create secure storage > on the SDcard. Rather, I'm looking for one file system that is accessed by > both Android applications and the PC, but still isolates Android > applications. That is, if AppA writes FileA, the default permissions keep > AppB from access it. However, when the phone is mounted on a PC, the user > can access FileA.
> Correct me if I'm wrong, but I don't think any of your solution provide > that functionality.
> Thanks,
> -Will
> Moses Roses wrote:
>> Hi, >> Basically is to create a partition which supports a stronger enabled FS. >> The 2 options I know of are : virtual disk via device mapper and real >> partition (FAT & EXT3) >> More elaboration on the methods: >> It is possible to have a virtual drive on the FAT, namely, you have one >> file on the FAT and that found is mounted (via device mapper) as a file >> system, meaning that you can have full yaffs2 or any other type of supported >> FS by the kerne. If you will use encrypted FS(dm-crypt), it will protected >> the visibility of file when mounted onto PC. >> You need to make sure that the kernel supports device mapper, and make >> sure that on the initial mounting table the new partition appears. >> A different method could be 2 partitions, one is FAT and the other any FS >> you want that the linux supports. For this method you can use simple tools >> such as gparted to do that.
>> Good Luck, >> Moses >> On Mon, Aug 3, 2009 at 11:24 PM, William Enck <e...@cse.psu.edu<mailto: >> e...@cse.psu.edu>> wrote:
>> Luis,
>> You might look into a suitable way of securing data on the SDcard. >> It's a FAT file system, so you can't use UNIX permissions to >> restrict applications. Officially, nothing sensitive is supposed to >> be placed on the SDcard. However, there are some situations (at >> least in my research) where it would be nice to show through some >> sort of analysis that two applications truly are isolated and can't >> share data, even through the SDcard.
>> The difficulty is that the SDcard needs to be FAT, because the PC >> mounts it. I read on one of the Android mailing lists a while back >> that there is a desire not to make kernel modifications to support >> such isolation. That may, or may not, be a requirement for you.
>> This leaves the question of how to add security to the SDcard in >> such a way that it still allows the user to access all of the files >> when mounted on a PC.
>> I've tried to get some Masters students here at Penn State to look >> at the problem, but no one bit (yet). It's not a particularly deep >> research problem, but it's something I'd like to see a good solution >> for. Part of your evaluation should look at how existing >> applications use the SDcard and whether or not your solution breaks >> these applications. Theoretically, Content Providers should be used, >> but this might not always be the case.
>> Best,
>> -Will
>> Luis wrote:
>> Hi all,
>> I am looking to contribute to Android security and at the same time >> write my thesis. >> I have experience in C++ programming as well as other languages; >> and >> also in coporate security management.
Moses Roses wrote: > Will, > The encryption is just an additional capability you can have once you > have a virtual partition. > As for having ext2/3 FS on microSD, well, you can use many freeware > addons for windows that can read it.
> Or...use a Samba server on Android to access the partition as a > "shared directory". > This way internally you have a FS which supports all the permissions > needed for isolation just as in internal memory, and a server which > provides good interoperability between linux-like platform to a > windows PC. The server gives another control mechanism for what you > want to expose to the PC (which is even better than the current > situation).
> If you want to read the MicroSD directly via a card reader - you will > need the addon freewares (just google a bit).
> I hope that helps... > Moses
> On Thu, Aug 6, 2009 at 2:44 AM, William Enck <e...@cse.psu.edu > <mailto:e...@cse.psu.edu>> wrote:
> Moses,
> I think my requirements were a little muddled when I was > describing the security mechanism I'm looking for. I'm not trying > to create secure storage on the SDcard. Rather, I'm looking for > one file system that is accessed by both Android applications and > the PC, but still isolates Android applications. That is, if AppA > writes FileA, the default permissions keep AppB from access it. > However, when the phone is mounted on a PC, the user can access FileA.
> Correct me if I'm wrong, but I don't think any of your solution > provide that functionality.
> Thanks,
> -Will
> Moses Roses wrote:
> Hi, > Basically is to create a partition which supports a stronger > enabled FS. The 2 options I know of are : virtual disk via > device mapper and real partition (FAT & EXT3) > More elaboration on the methods: > It is possible to have a virtual drive on the FAT, namely, you > have one file on the FAT and that found is mounted (via device > mapper) as a file system, meaning that you can have full > yaffs2 or any other type of supported FS by the kerne. If you > will use encrypted FS(dm-crypt), it will protected the > visibility of file when mounted onto PC. > You need to make sure that the kernel supports device mapper, > and make sure that on the initial mounting table the new > partition appears. > A different method could be 2 partitions, one is FAT and the > other any FS you want that the linux supports. For this method > you can use simple tools such as gparted to do that.
> Good Luck, > Moses > On Mon, Aug 3, 2009 at 11:24 PM, William Enck > <e...@cse.psu.edu <mailto:e...@cse.psu.edu> > <mailto:e...@cse.psu.edu <mailto:e...@cse.psu.edu>>> wrote:
> Luis,
> You might look into a suitable way of securing data on the > SDcard. > It's a FAT file system, so you can't use UNIX permissions to > restrict applications. Officially, nothing sensitive is > supposed to > be placed on the SDcard. However, there are some situations (at > least in my research) where it would be nice to show > through some > sort of analysis that two applications truly are isolated > and can't > share data, even through the SDcard.
> The difficulty is that the SDcard needs to be FAT, because > the PC > mounts it. I read on one of the Android mailing lists a > while back > that there is a desire not to make kernel modifications to > support > such isolation. That may, or may not, be a requirement for you.
> This leaves the question of how to add security to the > SDcard in > such a way that it still allows the user to access all of > the files > when mounted on a PC.
> I've tried to get some Masters students here at Penn State > to look > at the problem, but no one bit (yet). It's not a > particularly deep > research problem, but it's something I'd like to see a good > solution > for. Part of your evaluation should look at how existing > applications use the SDcard and whether or not your > solution breaks > these applications. Theoretically, Content Providers should > be used, > but this might not always be the case.
> Best,
> -Will
> Luis wrote:
> Hi all,
> I am looking to contribute to Android security and at > the same time > write my thesis. > I have experience in C++ programming as well as other > languages; and > also in coporate security management.
Additional PC client software doesn't doesn't quite meet the requirements I had in mind. The Samba thought is interesting, but if my speculations for how Android allows PCs mount the SDcard are correct, doing so _transparently_ is non-trivial. I'm really looking for something that has the same "feel" from the PC's perspective.
Oh well, I'll put this one back on the stack for a while. Maybe Luis will come up with a creative solution. He's the one looking for a thesis idea. I already have mine ;-).
> Will, > The encryption is just an additional capability you can have once > you have a virtual partition. > As for having ext2/3 FS on microSD, well, you can use many freeware > addons for windows that can read it.
> Or...use a Samba server on Android to access the partition as a > "shared directory". > This way internally you have a FS which supports all the permissions > needed for isolation just as in internal memory, and a server which > provides good interoperability between linux-like platform to a > windows PC. The server gives another control mechanism for what you > want to expose to the PC (which is even better than the current > situation).
> If you want to read the MicroSD directly via a card reader - you > will need the addon freewares (just google a bit).
> I hope that helps... > Moses
> On Thu, Aug 6, 2009 at 2:44 AM, William Enck <e...@cse.psu.edu> wrote:
> Moses,
> I think my requirements were a little muddled when I was describing > the security mechanism I'm looking for. I'm not trying to create > secure storage on the SDcard. Rather, I'm looking for one file > system that is accessed by both Android applications and the PC, but > still isolates Android applications. That is, if AppA writes FileA, > the default permissions keep AppB from access it. However, when the > phone is mounted on a PC, the user can access FileA.
> Correct me if I'm wrong, but I don't think any of your solution > provide that functionality.
> Thanks,
> -Will
> Moses Roses wrote: > Hi, > Basically is to create a partition which supports a stronger enabled > FS. The 2 options I know of are : virtual disk via device mapper and > real partition (FAT & EXT3) > More elaboration on the methods: > It is possible to have a virtual drive on the FAT, namely, you have > one file on the FAT and that found is mounted (via device mapper) as > a file system, meaning that you can have full yaffs2 or any other > type of supported FS by the kerne. If you will use encrypted FS(dm- > crypt), it will protected the visibility of file when mounted onto PC. > You need to make sure that the kernel supports device mapper, and > make sure that on the initial mounting table the new partition > appears. > A different method could be 2 partitions, one is FAT and the other > any FS you want that the linux supports. For this method you can use > simple tools such as gparted to do that.
> Good Luck, > Moses > On Mon, Aug 3, 2009 at 11:24 PM, William Enck <e...@cse.psu.edu <mailto:e...@cse.psu.edu > >> wrote:
> Luis,
> You might look into a suitable way of securing data on the SDcard. > It's a FAT file system, so you can't use UNIX permissions to > restrict applications. Officially, nothing sensitive is supposed to > be placed on the SDcard. However, there are some situations (at > least in my research) where it would be nice to show through some > sort of analysis that two applications truly are isolated and can't > share data, even through the SDcard.
> The difficulty is that the SDcard needs to be FAT, because the PC > mounts it. I read on one of the Android mailing lists a while back > that there is a desire not to make kernel modifications to support > such isolation. That may, or may not, be a requirement for you.
> This leaves the question of how to add security to the SDcard in > such a way that it still allows the user to access all of the files > when mounted on a PC.
> I've tried to get some Masters students here at Penn State to look > at the problem, but no one bit (yet). It's not a particularly deep > research problem, but it's something I'd like to see a good > solution > for. Part of your evaluation should look at how existing > applications use the SDcard and whether or not your solution breaks > these applications. Theoretically, Content Providers should be > used, > but this might not always be the case.
> Best,
> -Will
> Luis wrote:
> Hi all,
> I am looking to contribute to Android security and at the > same time > write my thesis. > I have experience in C++ programming as well as other > languages; and > also in coporate security management.
> Any ideas of topics where I could help?
> Luis
-- William Enck PhD Candidate Department of Computer Science and Engineering The Pennsylvania State University e...@cse.psu.edu
Android's API safety comes primarily from the Permission system and from the user's informed decision to install a given application. Certificates cryptographically link Permissions to sources of code and optionally to a Linux UID. In any case, CAs do not provide any measure of trustworthiness. CAs were supposed to help people link online identities with real-world identities, which is a distinct thing.
People seem to want to trust a central authority. That baffles me, given the performance of global, public CAs so far. (Google for "md5 considered harmful today" or "moxie marlinspike", or try to buy a certificate with the CN "email" and think about how bad it is that you were able to.) As security engineers we are trying to reduce the number of entities we have to trust, and the degree to which we have to trust them. Android's design helps users do both.
Android's security design is very different from that of PC operating systems. The user interface tells the user what they need to know to decide if they want to trust the application with the stated Permissions. This design allows Android users to put a smaller amount of trust in their applications; by contrast, PC operating systems typically require users to fully trust their applications.
Therefore trustworthiness is arguably less of an issue, since users place less trust in Android applications.
I would therefore say that a key security research area -- the original poster was looking for something to do -- is to research how to divide privilege into distinct units, and how to most effectively communicate their meaning to users.
> Android's API safety comes primarily from the Permission system and
> from the user's informed decision to install a given application.
> Certificates cryptographically link Permissions to sources of code and
> optionally to a Linux UID. In any case, CAs do not provide any measure
> of trustworthiness. CAs were supposed to help people link online
> identities with real-world identities, which is a distinct thing.
> People seem to want to trust a central authority. That baffles me,
> given the performance of global, public CAs so far. (Google for "md5
> considered harmful today" or "moxie marlinspike", or try to buy a
> certificate with the CN "email" and think about how bad it is that you
> were able to.) As security engineers we are trying to reduce the
> number of entities we have to trust, and the degree to which we have
> to trust them. Android's design helps users do both.
> Android's security design is very different from that of PC operating
> systems. The user interface tells the user what they need to know to
> decide if they want to trust the application with the stated
> Permissions. This design allows Android users to put a smaller amount
> of trust in their applications; by contrast, PC operating systems
> typically require users to fully trust their applications.
> Therefore trustworthiness is arguably less of an issue, since users
> place less trust in Android applications.
I want to learn more about the security architecture of Android (both
h/w and s/w). Where can I find such info?
PS. Telling the user about what user what they need to know (to decide
if they want to trust the application with the stated Permissions)
does not guarantee trustworthiness. It could be that there
is malware inserted between the platform and the app. I think only
when Android is deployed at the scale of Windows (and is deployed for
high-value transactions) will we hear about attacks and hear about
flaws. Has the Android team looked at Intel's TXT technology and
related h/w security from BRCM?
>> Android's API safety comes primarily from the Permission system and >> from the user's informed decision to install a given application. >> Certificates cryptographically link Permissions to sources of code >> and >> optionally to a Linux UID. In any case, CAs do not provide any >> measure >> of trustworthiness. CAs were supposed to help people link online >> identities with real-world identities, which is a distinct thing.
>> People seem to want to trust a central authority. That baffles me, >> given the performance of global, public CAs so far. (Google for "md5 >> considered harmful today" or "moxie marlinspike", or try to buy a >> certificate with the CN "email" and think about how bad it is that >> you >> were able to.) As security engineers we are trying to reduce the >> number of entities we have to trust, and the degree to which we have >> to trust them. Android's design helps users do both.
>> Android's security design is very different from that of PC operating >> systems. The user interface tells the user what they need to know to >> decide if they want to trust the application with the stated >> Permissions. This design allows Android users to put a smaller amount >> of trust in their applications; by contrast, PC operating systems >> typically require users to fully trust their applications.
>> Therefore trustworthiness is arguably less of an issue, since users >> place less trust in Android applications.
> I want to learn more about the security architecture of Android (both > h/w and s/w). Where can I find such info?
> PS. Telling the user about what user what they need to know (to decide > if they want to trust the application with the stated Permissions) > does not guarantee trustworthiness. It could be that there > is malware inserted between the platform and the app. I think only > when Android is deployed at the scale of Windows (and is deployed for > high-value transactions) will we hear about attacks and hear about > flaws. Has the Android team looked at Intel's TXT technology and > related h/w security from BRCM?
For the high level s/w, following the package installation flow is a pretty good way to start learning about permissions and signatures. The PackageInstaller (packages/apps/PackageInstaller) is the app that prompts the user about requested permissions. Once the user okays the install the package is passed to PackageManagerService.installPackage() (frameworks/base/services/java/ com/android/server/PackageManagerService). When PackageInstaller calls the PackageManagerService it's an ipc/binder call and so the service has to check whether the caller has the INSTALL_PACKAGE permission. This is how the system ensures that the user prompting hasn't been bypassed. You'll see at the beginning of the installPackage method a call to enforceCallingOrSelfPermission.
