One of the challenges facing the development of an integrated bibliography system on the Android platform, simply, arrives of the Android OS' app UID/GID model, moreover Android's application of the Linux filesystems permission model – in any ways augmented, as some documentation may denote, augmented with a mandatory access control (MAC) application extending of SE Linux, in light of the albeit not formally adopted POSIX 1003.1e i.e "POSIX 1e" draft, in Android KitKat and other Android release branches. POSIX 1e finds application in Linux, furthermore, with the Linux process capabilities implementation. Analogously, in the FreeBSD operating system, POSIX 1e find application in the FreeBSD MAC implementation and in the Capsicum implementation.
Not as if to abjectly criticize the Google Android project – the app/filesystem permissions model in KitKat being of some notable inconvenience for file storage to SD card media, in Android platforms – there is probably a logic to the changes made with regards to these features, in Android 4 i.e "Kit Kat" and other Android release branches. (Ed note: cf. Android Content Providers [AndrDeveloperST]) Whatever ways in which the MAC model may be involved in the issue, it may seem to center primarily about app UID specification – the issue of the inonvenience for platform users, as with regards to files that must be accessed with multiple Android apps on a single Android appliance – whether or not specifically to access files stored on external SD card media, logically an orthogonal concern, orthogonal to the permissions model of a Google certified Android appliance's own on-device storage meda, there with further orthogonal reference to filesystem types (bibliography on file).
On the Android platform, app UID and GID is computed at time of app installation[AndrDeveloper]. App UID and GID information on the Android platform is not stored in the common text and shadow files under the /etc directory – common insomuch as with regards to UNIX platforms applying a POSIX and X/Open model. Rather, in one regards, UID and GID information is stored – on the Android platform – as with reference to an 'acct/uid' directory[BD2015]. (Ed. note: See also, the GET_ACCOUNTS manifest permission [AndrAPI_Mperm])
From a developer's perspective, there are application settings available for sharing an app's identity with an existing app, inasmuch as with regards to the sharedUserID attribute [AndrDeveloperPerms] of a single app's APK manifest description. The corresponding sharedUserLabel APK manifest field, moreover, allows for human-readable labeling of apps' shared user ID[AndrAPI_R], Albeit, the sharedUserLabel may be applied to an ambiguous situation – as with regards to that a sharedUserLabel may be specified in one app's APK manifest, but would be applied for a UID shared among multiple apps. This article will not further investigate how the Android OS may establish a systematic precedence to shared user labels, as in a conflict of differring sharedUserLabel specifications for a single sharedUserID.
In addition to the sharedUserID APK manifest attribute, the Android API defines a permissionGroup object type [AndrAPI_R], corresonding to a 'permission-group' tag as may be specified in an Android APK manifest file[AndrAPI_RStyleable]
Referring to the reference documentation about these multiply-linked OS features, in Android, it seems there is an Account Service in the Android OS, specifically referencing the GET_ACCOUNTS manifest permission [AndrAPI_Mperm] – perhaps an elusive feature of the Android Operating System, the Android OS Account Service.
There is inquiry of a topic as with regards to storage of user account information on the Android platform. [OvOp2015] Probably, the Android OS Account Service may be a topic of a commonly linked reference, as with regards to APK principal peer identity, and UID and GID values computed at time of APK install.
(Ed. Note: Or not. On further study, it seems that the Android Account Service is rather a service for managing a user's web account information, centrally, on any single Android appliance.)
Perhaps this study may be extended of, as with regards to applying Kerberos as a neteork peer authentication service on Android appliances. There is some of an existing work, with regards to implementing Kerberos services on the Android platform (bibliography on file), though perhaps nothing immediately about whether or not a network admin should allow authentication to a network service, e.g SSH, with a Kerberos ticket from a thin client appliance – an orthogonal topic, certainly. For web apps, of course there's OAuth/OAuth2.
[Article Draft Nr. 2]
Perhaps this study may be extended of, as with regards to applying Kerberos as a neteork peer authentication service on Android appliances. There is some of an existing work, with regards to implementing Kerberos services on the Android platform (bibliography on file), though perhaps nothing immediately about whether or not a network admin should allow authentication to a network service, e.g SSH, with a Kerberos ticket from a thin client appliance – an orthogonal topic, certainly. For web apps, of course there's OAuth/OAuth2.
[Article Draft Nr. 2]
Webliography
[Anderson2013] http://www.all-things-android.com/content/deeper-look-android-application-permissions
[BD2015] http://boundarydevices.com/android-security-part-1-application-signatures-permissions/
[AndrDeveloperPerms] http://developer.android.com/guide/topics/security/permissions.html
[AndrAPI_R] http://developer.android.com/reference/android/R.attr.html
[AndrAPI_RStyleable] http://developer.android.com/reference/android/R.styleable.html#AndroidManifestPermissionGroup
[AndrDeveloperST] http://developer.android.com/training/articles/security-tips.html
[AndrAPI_Mperm] http://developer.android.com/reference/android/Manifest.permission.html
[OvOp2015] http://android.stackexchange.com/questions/74969/where-is-user-group-id-info-stored-on-android-and-how-do-i-inerpret-it
No comments:
Post a Comment