On Thu, 2007-08-02 at 00:01 -0700, Louis Lam wrote: > Today i managed to make the vmplayer run in its own domain. What I did > was added the statement to my vmware.te. Thanks to Ken and his > suggestion (and all of the help so far), i've got the "Selinux by > example" book that i've been reading as a reference. > > domain_auto_trans(unconfined_t, vmware_exec_t, vmware_t) > > Evident from the large amount of avc denials in setroubleshoot when i > launch vmplayer, i was able to see that vmplayer was running in the > context of : > > root:system_r:vmware_t > > Two questions from security angle on this approach though: > > 1. If i allow transition from unconfined_t to vmware_t, it means that > any unconfined process can transit to vmware_t and be able to access > the vmware files. This is probably not what i'd desire. What would be > a good recommendation for this? Any best practices? It doesn't matter, unconfined_t is unconfined; therefore, it already has access to vmware files. > 2. I still want to start vmware as a user program, probably not as a > service. In that case, would I still need to do something in the > vmware.if so that the domain auto trans can take on a role ? I don't understand this question. Vmware has daemon parts for the vmnets, and the user application is the player itself. > Now that i'm able to run it under vmware_t domain, and see a lot of > avcs, i intend to make vmware run properly again. I'd go with allowing > whatever vmware wants to do, then tightening the security. There are a > few approaches i can use, and i'd like to seek your opinions on how to > go about doing it: > > 1. audit2allow: This will list all of the avcs and turn them into > allow statements. By adding these statements to my vmware.te, this > would enable vmware to function again. Problem is that i may end up > with too many statements. Correct. > There would probably be macros to cover these. There should already be sufficient existing interfaces, since there is policy, though I tested it with vmware workstation, not the player (I don't imagine they are very different access-wise). > 2. macros: This is somethings i'm not familiar with. Are there any > documentation that describe some of the more commonly used macros? Or > it is better just to see the source? By looking a few of the source files, you can see the commonly used interfaces. You can also look at the interface documentation, but it has all the macros, not just the common ones: http://oss.tresys.com/docs/refpolicy/api > 3. policygentool: From what i understand, this is a script that would > generate a module for you. the question is how do i combine it with > the vmware source code that I've taken from the reference policy? > (that i'm using now)? I forsee a lot of conflicts to be resolved. and > may actually not be so clean. I believe this tool is designed to be run on a service that doesn't already have a policy. It just gets you a starting point, creating some types, some interfaces, and a handful of common rules (leveraging refpolicy interfaces). -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
