{"id":58,"date":"2017-03-22T19:34:28","date_gmt":"2017-03-22T19:34:28","guid":{"rendered":"http:\/\/bocchinfuso.net\/?p=58"},"modified":"2017-04-06T18:20:27","modified_gmt":"2017-04-06T18:20:27","slug":"fit-mgt5114-wk3-discussion-1-post","status":"publish","type":"post","link":"https:\/\/bocchinfuso.net\/index.php\/2017\/03\/22\/fit-mgt5114-wk3-discussion-1-post\/","title":{"rendered":"FIT MGT5114 \u2013 Wk3 Discussion 1 Post"},"content":{"rendered":"

Question:<\/strong><\/p>\n

The traditional protection levels used by operating systems to protect files are read, write, and execute. What are some other possible levels that a user may wish to apply to files, folders, code, etc.? Justify your answers with examples.<\/p>\n

Response:<\/strong><\/p>\n

File and folder permissions are governed slightly differently based on operating system type, but the constructs are the same. On Unix<\/a> and other POSIX<\/a>-compliant systems (Linux<\/a>, Android, MacOS, Windows NTFS<\/a>, etc…) file and folder permissions are managed using a user, group, others (or world) model.<\/p>\n

For example:
\nfoo.bar sticky bit | owner | group | world
\nfoo.bar – | rwx | r-x | r-x (-rwxr-xr-x)<\/p>\n

Files and folders can have permissions quickly set for Owner, Group and World by using the numeric value for the permission mask.
\nr (read) = 4
\nw (write) = 2
\nx (execute) = 1<\/p>\n

To assign the file “foo.bar” the permission mask of:
\nowner = rwx
\ngroup = r-x
\nothers = r-x
\nThe command would be “chmod<\/a> 755 foo.bar”<\/p>\n

Unix based systems leverage three additional permission sticky bit, setuid and setgid<\/a>.
\nWhen the setuid permission is set the user executing the file assumes the permissions of the file owner.
\nWhen the setgid permission is set the user executing the file is granted the permissions based on the group associated with the file.
\nWhen the sticky bit is set a file or directory can only be deleted by the file owner, directory owner or root.<\/p>\n

These special permissions are set in the following fashion:
\nsticky bit = 1000
\nsetgid = 2000
\nsetuid = 4000<\/p>\n

Same idea as setting file permissions to set the sticky bit on foo.bar with full permissions the command would be “chmod 1777 foo.bar. To setgid and setuid with rwx permissions for the owner and no read only permissions for the group and others the command would be “chmod 6744 foo.bar”.<\/p>\n

Windows based systems follow a similar file and folder permissions construct at least on systems using the POSIX-compliant NTFS file system (most modern Windows OSes). Older Microsoft Operating Systems like MS-DOS (FAT16 file system) and Windows 95 (FAT32 file system)<\/a> use file attributes (Read-Only or Read-Write) rather than a full permission systems.<\/p>\n

Permission inheritance is an important concept, the setgid and setuid are use to facilitate inheritance, the application is slightly different on Windows Operating Systems, but the premise is the same.<\/p>\n

Source code can be protected in various ways outside of just file permissions. One option is to compile the code making it executable but not readable. Compiled languages like C++ compile into machine code<\/a>; these compiled binaries are not easily decompiled<\/a>, another option is to use a bytecode<\/a> compiler often used with interpreted languages like Python, Perl, Ruby, etc… Machine code needs to be compiled for specific architectures, for example, x86, x64 and ARM would require three separate binaries while bytecode compiled binaries would work across architectures. The downside with bytecode compiled binaries is that most of the source code is contained in the compiled binary making it far easier to decompile.<\/p>\n

Daemons and like auditd<\/a> provide the ability to maintain detailed audit trails on file access. Systems like Varonis<\/a> provide the ability to audit and verify permissions to ensure that the proper permissions are assigned to files and folders.<\/p>\n

Outside of file and folder permissions, there are application level permissions such as RDBMS permissions<\/a> which determine how a user can interact with the RDBMS and the data it houses. Object store permissions like AWS S3<\/a> offer an authorization model which is similar to filesystem permissions, and these permissions are typically managed via API using standard authentication methods like OAuth2<\/a> and SAML<\/a> token based authentication. NAC or Network Access Control<\/a> is a system which controls network access and manages security posture. Revision Contol Systems like Git<\/a> use Access Controls to protect source code, in the case of Git these ACLs are very similar to UNIX-based ACLs. Many systems today which leverage REST<\/a> and SOAP<\/a> APIs to access date use tokens<\/a> and keys to authenticate users and grant rights. I just finished working on some code today (https:\/\/gist.github.com\/rbocchinfuso\/36f8c58eb93c4932ec4d31b6818b82e8<\/a>) for a project which uses the Smartsheet API<\/a> and token based authentication so that cells can be updated using a command from Slack<\/a>. This code authenticates using a token contained in an unpublished config.inc.php file and allows fields in a Smartsheet to be toggled using a command similar to “ssUpdate rowID,columnID,state”. Token based authentication, in this case, can provide VIEWER, EDITOR, EDITOR_SHARE, ADMIN and OWNER (https:\/\/smartsheet-platform.github.io\/api-docs\/#authentication<\/a>) privileges while being stateless and without requiring user and password authentication.<\/p>\n

References<\/strong><\/p>\n

Pfleeger, C. P., Pfleeger, S. L., & Margulies, J. (2015). Security in computing (5th ed.). Upper Saddle River: Prentice Hall.<\/p>\n","protected":false},"excerpt":{"rendered":"

Question: The traditional protection levels used by operating systems to protect files are read, write, and execute. What are some other possible levels that a user may wish to apply to files, folders, code, etc.? Justify your answers with examples. Response: File and folder permissions are governed slightly differently based on operating system type, but […]<\/p>\n","protected":false},"author":1,"featured_media":37,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,4,2],"tags":[],"_links":{"self":[{"href":"https:\/\/bocchinfuso.net\/index.php\/wp-json\/wp\/v2\/posts\/58"}],"collection":[{"href":"https:\/\/bocchinfuso.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bocchinfuso.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bocchinfuso.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/bocchinfuso.net\/index.php\/wp-json\/wp\/v2\/comments?post=58"}],"version-history":[{"count":2,"href":"https:\/\/bocchinfuso.net\/index.php\/wp-json\/wp\/v2\/posts\/58\/revisions"}],"predecessor-version":[{"id":60,"href":"https:\/\/bocchinfuso.net\/index.php\/wp-json\/wp\/v2\/posts\/58\/revisions\/60"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bocchinfuso.net\/index.php\/wp-json\/wp\/v2\/media\/37"}],"wp:attachment":[{"href":"https:\/\/bocchinfuso.net\/index.php\/wp-json\/wp\/v2\/media?parent=58"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bocchinfuso.net\/index.php\/wp-json\/wp\/v2\/categories?post=58"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bocchinfuso.net\/index.php\/wp-json\/wp\/v2\/tags?post=58"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}