{"id":19837732,"url":"https://github.com/willghatch/cs6490-permissions-project","last_synced_at":"2026-03-02T21:41:15.267Z","repository":{"id":75536572,"uuid":"48254399","full_name":"willghatch/cs6490-permissions-project","owner":"willghatch","description":"Permissions project for security class","archived":false,"fork":false,"pushed_at":"2015-12-18T20:12:15.000Z","size":77,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-01-11T11:15:29.987Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"TeX","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/willghatch.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-12-18T20:11:29.000Z","updated_at":"2015-12-18T20:12:17.000Z","dependencies_parsed_at":"2023-03-15T17:15:47.108Z","dependency_job_id":null,"html_url":"https://github.com/willghatch/cs6490-permissions-project","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/willghatch%2Fcs6490-permissions-project","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/willghatch%2Fcs6490-permissions-project/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/willghatch%2Fcs6490-permissions-project/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/willghatch%2Fcs6490-permissions-project/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/willghatch","download_url":"https://codeload.github.com/willghatch/cs6490-permissions-project/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":241202617,"owners_count":19926651,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-12T12:15:25.062Z","updated_at":"2026-03-02T21:41:15.204Z","avatar_url":"https://github.com/willghatch.png","language":"TeX","funding_links":[],"categories":[],"sub_categories":[],"readme":"Here is, more or less, my plan:\n\nThe premise:\n------------\n\nUnix permissions are insufficient -- they are good for permissions between\nusers, but do not help with the issue of a user wanting to run less-trusted\ncode.  Android permissions are inflexible (IE all permissions are enumerated by\nthe OS and dictated by Google), and all-or-nothing (you can't run a program\nwith partial permissions), it hijacks the user/group security of Unix\n(therefore killing its usefulness as a multi-user system [Can I just rant a\nbit?  This was a grossly stupid decision.  Every type of computer is often used\nby many users.  Even in first world countries.  What if I want to let a\nstranger make a phone call but not access my email?  What if I want to let a\nkid play Angry Birds but not send prank texts?  What if siblings want to keep\ntheir settings and saved games separate on their shared tablet?  Why did\nAndroid repeat the mistakes Windows made in the 90's?]), and its interface is\nbad (you agree to everything up-front, out of context).\n\nThe solution:\n-------------\n\n- A run of a program is a combination of a \"permission context\" and an\n  executable (this allows common programs or libraries to be re-used securely,\n  without needing all programs using a library or sub-process to declare\n  needing all permissions used by it).  If a function requiring permission is\n  called in a context lacking that permission, an exception is raised.\n- Some permissions (eg. file system, network) are standard and \"come with the\n  OS\", other permissions can come from other programs - a program or library\n  can declare new permissions to extend this base set.\n- Permissions can be parameterized -- Eg. file system access won't be like\n  Android's nonsense \"can access everything on SD card\" vs accessing nothing.\n  You can have things like (permission 'file-system-read \"~/some/path\").\n  Possibly (permission 'network \"some.domain.example.com\").  I think there\n  should be some sort of blacklisting available to mark file system subtrees to\n  be private, and denied unless the permission for that sub-tree is explicit -\n  eg. (permission 'file-system-read \"/home/user\") gets permission to all the\n  child directories, except not to \"/home/user/.ssh\" because it is blacklisted\n  in this way.  I'm not sure quite what the interface on this should be, or how\n  it should be configured yet.\n- It should be configured in some format amiable both to novice computer users\n  who will use menu-driven GUI stuff to configure, as well as to people who\n  configure everything in a text editor and track it in git.  IE it should work\n  for interactive use with GUI apps and for pre-configuration for sysadmins and\n  such.\n- When a permission is needed that isn't already granted, a pop-up window can\n  ask a user whether the permission should be granted (eg. yes/no/yes always/no\n  always) so a user will understand the context the permission is needed in --\n  if the user requested network access, then the permission makes sense.  If\n  the request comes unexpectedly, then users will have reason to be more\n  suspicious.  A configuration option will be available for the sysadmin types\n  to simply reject interactive permission escalation.\n- Apps can ship with a file that gives a minimal permission context to run in.\n  They would presumably live in a directory like unix's .desktop files for apps\n  live in.  Users would have a directory in their home that mirrors this to be\n  able to save overrides to these contexts or add more (eg when you say an app\n  can always use X permission).  These default permission sets could be shown\n  at install-time similar to Android -- but they should really be minimal and\n  probably usually empty.\n- There are some more details I've thought about (eg. that some permissions\n  would offer access to services given by daemons or programs that could be run\n  on-demand, and probably these permissions would also have to be declared\n  similarly with files in some directory), but that are probably outside the\n  scope of our proof-of-concept project.\n- There is presumably some \"full-user\" context that will essentially get all\n  permissions for a user, similar to how the root user gets full access to a\n  unix system regardless of specified permissions.  In other words, running in\n  this permission context would be the same as Unix is now.\n\nThe implementation plan:\n------------------------\n\nWe use Racket and make a new #lang language that exports functions for wrapping\nthings in permission checks, wraps things like file opening in a permission\ncheck, make sure any sub-processes or other racket programs run in the same VM\ncannot escalate privileges, and generally deals with all permission stuff.\nPrograms written in this #lang will then be permissions-checked.  We will work\nout some interface for telling a process what permission context to run in if\nnot the default, and how/when changing contexts/escalating is allowed (eg. a\nuser in a shell with full-user permissions may want to run the shell's\nsubprocess apps with their default permission contexts, or inheriting the\ncurrent permission context.  Or one app may launch another app, but should the\nnew app run in its default context or in the context of the app that launches\nit?  There are probably times when both are desired.).\n\nGranted, this implementation will only secure things that are written in this\nracket dialect, but this really wants to be an OS-level system, but OS hacking\nwould take a lot more effort to make a proof of concept with.\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwillghatch%2Fcs6490-permissions-project","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fwillghatch%2Fcs6490-permissions-project","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwillghatch%2Fcs6490-permissions-project/lists"}