Skip to main content
7 events
when toggle format what by license comment
Apr 5, 2013 at 15:58 comment added peterph Thanks for the discussion - do you have any preferred resources that discuss this?
Apr 5, 2013 at 15:46 comment added user2213 @peterph they have to be vague, unfortunately - subject is usually a process but could also be a thread, object can be a file, shared memory, a pipe, a tcp socket, action could be any system call you can imagine - so yes, you're right, it's about the precise border. MAC defines that much much more rigorously than DAC.
Apr 5, 2013 at 15:21 comment added peterph OK I see the point, then the definitions you have used in the answer seem to be too vague - the triple (subject = code running with privileges of a particular user, object = file, action = open object) satisfies the definitions. Basically it revolves around the precise border between subject and action. Or is it that I have wrong lexical context (i.e. the system one instead of the security one)?
Apr 5, 2013 at 14:55 comment added user2213 As a practical example, on Fedora based systems, apache runs as http_exec_t transitioning to httpd_t and can access files labelled httpd_sys_content_t. It runs as whichever user you let it run as, say wwwuser, but if the files in /var/www are not labelled correctly it will not be able to see them.
Apr 5, 2013 at 14:53 comment added user2213 @peterph the basic difference is that each process under DAC inherits the permissions you have, whereas under MAC it does not. So when you run a process, say, "echo", it runs as you and can do anything you can. In that sense it is discretionary since the process is just assumed to have the same permissions you have regardless. This isn't true of MAC systems, where processes only inherit permissions like that if the rules say they can. Instead, "echo" runs with its own permissions. It is possible to configure a file to be readable in vim, but not via echo, for example.
Apr 5, 2013 at 13:59 comment added peterph I have to admit I don't really understand your answer - any process (read "code") running on a UNIX system has some defined rights. Yet these are set by the administrator and enforced by the kernel (at least in theory) - the user has nothing to do with it and in most cases can do nothing to change it. The exception is elevating one's privileges through su and similar, but these are again system wide policies. The answer would make sense to me if one changed inherit/assume the permissions to change the permissions to the object though. Would that make sense?
Apr 5, 2013 at 10:32 history answered user2213 CC BY-SA 3.0