{
	"id": "9de2fe6e-c6a5-4559-a71a-206663dbc661",
	"created_at": "2026-10-18T03:15:43.656647Z",
	"updated_at": "2026-10-20T09:12:48.342989Z",
	"deleted_at": null,
	"sha1_hash": "0461d0d9c1046cb34c4a28f1055594496f2e4928",
	"title": "[developer preview] Overly restrictive SELinux filesystem permissions in Android N [37091475]",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 33988,
	"plain_text": "https://code.google.com/p/android/issues/detail?id=205565\n\n[developer preview] Overly restrictive SELinux filesystem\n\npermissions in Android N [37091475]\n\nPublished: 2016-03-31 · Archived: 2026-10-18 02:28:14 UTC\n\n@22\n\nUnfortunately this is right.\n\nThe accessibility/capability allowed for years, do not suggest they should be accessable:\n\nAndroid initially has no permission control mechanism,\n\nWhile Blackberry have adopted it at the very begging, Apple have introduced it from iOS 6 which was released in\n\nSep 2012.\n\nApple's AppStore makes sure an app cannot force user to grant a permission(by terminating itself after the user's\n\ndeny).\n\nThe AppOpsManager class(the base part of the current runtime permission model) appeared in Android 4.3(July\n\n2012), and it has not become available to end users until marshmallow(oct 2015).\n\nWhat have Apple done in the 3 years?\n\nAlready have:\n\nmandatorily full-disk encryption\n\nstrict sandboxing that apps not able to see each other/very limited shared data store\n\n1, They disallowed access to deviceID/IMEI/device MAC, and provide several non\n\n-persistent ids(app id, vendor id, adid) as replacement.\n\n2, They made the iOS device to send randomized/fake MAC when the device is not connecting to a hotspot.\n\n3, They import the activation protection to the iOS device.\n\n4, They limit some APIs' capabilities to protect privacy:\n\n4.1 They limited visibility of shareable apps to limit installed app detection.\n\n4.2 They made face recognition process/data stored locally(Google photo does not).\n\n4.3 They have built a obscured analytics that individual telemetry data is mixed with noise.\n\nCurrent Android have adopted(some are partially) nearly each one listed above.\n\nSo it is not even \"accessibility/capability allowed for years\",\n\nit is actually a continues process that people are getting aware that \"they should not be accessed\".\n\n\"Fixing a security problem\" and \"revoking an accessibility/capability\" are becoming the same thing, since\n\nlogically you are not able to detect a security vulnerability before it occurs.\n\nPage 1 of 2\n\nhttps://code.google.com/p/android/issues/detail?id=205565\n\nThe change(separation and isolation) of the vulnerable mediaserver since Android 7 is a good example.\n\nMoreover, some accessibility/capability have not been recognized as privacy involved:\n\nDo a normal user(of course it is not you) understand that, if an app is allowed to scan nearby callular station id,\n\nwifi hotspot or bluetooth beacon, it is equivalently allowed to get pretty precise location information.\n\nAre the average users able to take responsibility if their device opens up these sensitive accessibility?\n\nSource: https://code.google.com/p/android/issues/detail?id=205565\n\nPage 2 of 2",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://code.google.com/p/android/issues/detail?id=205565"
	],
	"report_names": [
		"detail?id=205565"
	],
	"threat_actors": [],
	"ts_created_at": 1792293343,
	"ts_updated_at": 1792487568,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0461d0d9c1046cb34c4a28f1055594496f2e4928.pdf",
		"text": "https://archive.orkl.eu/0461d0d9c1046cb34c4a28f1055594496f2e4928.txt",
		"img": "https://archive.orkl.eu/0461d0d9c1046cb34c4a28f1055594496f2e4928.jpg"
	}
}