LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
LinkBack Search this Thread
Old 01-31-2012, 10:35 PM   #1
shadowbox12
Member
 
Registered: Mar 2010
Posts: 50

Rep: Reputation: 3
Restricting app with custom SELinux policy


I'm wanting to lock down Virtualbox and since I can't find any pre-made policy I need to create one. Using the SELinux Policy Generation Tool in CentOS 6 I created a fairly generic policy following the "User Application" template.

The policy defined the VirtualBox_exec_t, VirtualBox_rw_t, and VirtualBox_t types then set labels on the program directories. I loaded the new module and set it as permissive, then ran the program to generate AVCs I could import into audit2allow.

The problem is that simply starting the app and loading a VM and shutting it down straight away generated more than 600 AVC entries, the vast majority of which I don't understand. I could just dump the whole lot into audit2allow without checking, but that strikes me as poor security practice. If I want shoddy or no security I can just leave the app unconfined.

Just a quick glance shows several AVCs about access to the /home folders, which I know is not needed. Virtualbox keeps VMs in the user home folder by default, but I've put mine in another location so there is nothing in home for it need. Who knows what other access rights I could end up giving away without realizing it? It may default to check for write access to files it only needs read access to, but which still generates write access AVC entries which I would somehow have to pick out from the rest.

How in the world can I make sense of the deluge of AVC entries? All my searching on the net for instructions on creating policy has mostly turned up info 5 years old or older. I'm wondering if what I'm trying to accomplish is even feasible or will require either blanket allow permissions defeating the purpose or reverse engineering the entire application including every syscall and some kind of debugger.
 
Old 02-02-2012, 10:25 AM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,518
Blog Entries: 51

Rep: Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598
Quote:
Originally Posted by shadowbox12 View Post
The problem is that simply starting the app and loading a VM and shutting it down straight away generated more than 600 AVC entries, the vast majority of which I don't understand.
Could you pipe the AVC messages through audit2allow and attach the result as plain text?
 
Old 02-02-2012, 08:37 PM   #3
shadowbox12
Member
 
Registered: Mar 2010
Posts: 50

Original Poster
Rep: Reputation: 3
Quote:
Originally Posted by unSpawn View Post
Could you pipe the AVC messages through audit2allow and attach the result as plain text?
Absolutely! I'd love to have someone who can actually understand these messages look at it. I've cleaned it up a bit since I first posted this. I found some files mislabeled as default_t that was generating some denials. Looking through the log, I can see some that are clearly wrong and some that it clearly needs. The problem is about 80% I don't have a clue what it is asking for or what the security implications would be of granting. For example, virtualbox wants read/write access to devpts. Ok, that could mean it just wants to read and write to the terminal I launched it from, or that could mean it wants global read write and by granting that I allow it to read and write from a separate terminal that has su open.
Attached Files
File Type: txt vbox.te.txt (11.9 KB, 15 views)
 
Old 02-03-2012, 09:42 PM   #4
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,518
Blog Entries: 51

Rep: Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598
Sure it has to deal with 96 other contexts and 11 classes but taking into account what kind of application VirtualBox is, what tasks it has to perform to be able to run a guest OS, I think your policy file looks pretty much OK.

From the set of { add_name, associate, connectto, create, destroy, execmem, execmod, execute, execute_no_trans, getattr, ioctl, lock, open, read, remove_name, rename, rmdir, search, setcap, setpgid, setrlimit, setsched, signal, signull, unix_read, unix_write, unlink, write } access types the only ones I would investigate are those that force conditions beyond what's ordinarily necessary like exec{heap,mem,mod} (read http://people.redhat.com
/~drepper/selinux-mem.html), some set.* like setcap, setsched and setrlimit, ioctl (syscalls not covered by other types of permission) and execute_no_trans (exec file in VirtualBox_rw_t or bin_t w/o transitioning from VirtualBox_t).
 
1 members found this post helpful.
Old 02-05-2012, 05:34 PM   #5
shadowbox12
Member
 
Registered: Mar 2010
Posts: 50

Original Poster
Rep: Reputation: 3
Quote:
Originally Posted by unSpawn View Post
Sure it has to deal with 96 other contexts and 11 classes but taking into account what kind of application VirtualBox is, what tasks it has to perform to be able to run a guest OS, I think your policy file looks pretty much OK.

From the set of { add_name, associate, connectto, create, destroy, execmem, execmod, execute, execute_no_trans, getattr, ioctl, lock, open, read, remove_name, rename, rmdir, search, setcap, setpgid, setrlimit, setsched, signal, signull, unix_read, unix_write, unlink, write } access types the only ones I would investigate are those that force conditions beyond what's ordinarily necessary like exec{heap,mem,mod} (read http://people.redhat.com
/~drepper/selinux-mem.html), some set.* like setcap, setsched and setrlimit, ioctl (syscalls not covered by other types of permission) and execute_no_trans (exec file in VirtualBox_rw_t or bin_t w/o transitioning from VirtualBox_t).
Thanks, that is extremely helpful. I'll look those up tonight. I think it may be trying to exec files labelled VirtualBox_rw_t because several executable files are in the main program directory which got labelled VirtualBox_rw_t. Is there a way to label files in a dir differently than the parent dir in such a way that it will survive a system relabel? Should I give each executable a separate exec_t label or lump them all into VirtualBox_exec_t?
 
Old 02-06-2012, 11:39 AM   #6
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,518
Blog Entries: 51

Rep: Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598
Quote:
Originally Posted by shadowbox12 View Post
Is there a way to label files (..) in such a way that it will survive a system relabel?
'semanage fcontext -a -t {label} {item} would add an exception to your /etc/selinux/{policy}/modules/active/file_contexts.local.


Quote:
Originally Posted by shadowbox12 View Post
Should I give each executable a separate exec_t label or lump them all into VirtualBox_exec_t?
Within a daemon policy it is customary to separate _t, _rw_t and _exec_t contexts. In theory you should give each binary a separate _exec_t label if you would be working with several related _t contexts needing transition to several _exec_t contexts but then I think it gets convoluted RSN. I'd keep them in VirtualBox_exec_t.
 
Old 02-16-2012, 10:37 PM   #7
shadowbox12
Member
 
Registered: Mar 2010
Posts: 50

Original Poster
Rep: Reputation: 3
@unSpawn After several evenings working on this I feel I'm finally getting a handle on it. Most of the {exec*} denials were being caused by a few lingering mislabelings. Rather than using semanage to do this I've been adding the correct labels to the fc file as I intend to post the entire policy for others to use.

I did find one TEXTREL problem, I believe, as the site you linked to mentioned. This was generating execmem denials. I'll be reporting it to the Virtualbox developers as a bug. Hopefully something will be done about it. Until then I suppose I could set the execmen boolean or set that policy to "no audit".

There are a few other avc denials I'm concerned with though. Can you offer any insight on these?

Feb 16 21:28:06 (null) (null): audit(1329449286.802:1312): avc: denied { execute_no_trans } for pid=9276 comm=virtualbox path="/sbin/lsmod" ino=29622352 dev=dm-1 scontext=unconfined_u:unconfined_r:VirtualBox_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file

There are 2 exec_no_trans denials, one for lsmod and one for grep. I'm not sure what to do with these. I think one option would be to write a transition rule to bin_t, but it seems that would basically allow Virtualbox to execute anything in /bin which seems overly broad.

There are 2 denials related to the unconfined domain, which seems particularly sensitive to me as I thought the whole point of SE Linux is to separate confined applications from unconfined ones.

Feb 16 21:28:06 (null) (null): audit(1329449286.835:1394): avc: denied { open } for pid=9279 comm=ps name=stat ino=22259 dev=proc scontext=unconfined_u:unconfined_r:VirtualBox_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0 tclass=file

Feb 16 10:45:24 (null) (null): audit(1329410724.427:303): avc: denied { connectto } for pid=2876 comm=VirtualBox path=002F746D702F2E4943452D756E69782F32363138 scontext=unconfined_u:unconfined_r:VirtualBox_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=unix_stream_socket

One thing I've noticed is a majority of the denials show "comm=ps" and "name=stat". These show up under a variety of contexts: syslogd_t, kernel_t, rpcbind_t, etc. I'm guessing Virtualbox is executing ps and piping the output through stat for some reason. Seems harmless enough, but I'm wondering if there is a simple way to allow this without having to create an allow rule for each different context it shows up under. Fix the root of the problem as it were.

It looks like most of the {set*} permissions you suggested I look into relate to VirtualBox_t self:process. I'm not really clear on what that is about, but it seems fairly harmless to allow it modify itself. Is there something about this I should be paying attention to?
 
Old 02-17-2012, 12:32 PM   #8
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,518
Blog Entries: 51

Rep: Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598
Quote:
Originally Posted by shadowbox12 View Post
Most of the {exec*} denials were being caused by a few lingering mislabelings. Rather than using semanage to do this I've been adding the correct labels to the fc file as I intend to post the entire policy for others to use.
Good decision. And TIA for sharing. When will you be posting it and where?


Quote:
Originally Posted by shadowbox12 View Post
I did find one TEXTREL problem, (..) This was generating execmem denials.
Hmm. For me text relocation errors (== library developer mistakes) occur with libraries only, not binaries. If I 'grep -c textrel_shlib_t file_contexts.local' I get about 32 library entries for VLC, Google Earth, Firefox and a few other packages.


Quote:
Originally Posted by shadowbox12 View Post
(..) Until then I suppose I could set the execmen boolean or set that policy to "no audit".
I'd rather you allow VirtualBox_t execmem as that confines things to that context. Setting the policy to "no audit" only means no warnings are generated. To put things in perspective if I 'sesearch -a|grep -c execmem' I get 200+ rules so while it's bad it's not like SELinux doesn't anticipate fixing this in the default targeted policy for a slew of domains including semanage_t and semanage_gui_t ;-p


Quote:
Originally Posted by shadowbox12 View Post
Feb 16 21:28:06 (null) (null): audit(1329449286.802:1312): avc: denied { execute_no_trans } for pid=9276 comm=virtualbox path="/sbin/lsmod" ino=29622352 dev=dm-1 scontext=unconfined_u:unconfined_r:VirtualBox_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file

There are 2 exec_no_trans denials, one for lsmod and one for grep. I'm not sure what to do with these. I think one option would be to write a transition rule to bin_t, but it seems that would basically allow Virtualbox to execute anything in /bin which seems overly broad.
Agree.


Quote:
Originally Posted by shadowbox12 View Post
There are 2 denials related to the unconfined domain, which seems particularly sensitive to me as I thought the whole point of SE Linux is to separate confined applications from unconfined ones.
The default targeted policy basically hardens 'net-facing services, unprivileged users for instance run in the unconfined domain. For a "privileged" service to read or write to unconfined_t is not (or should not be) problematic, it's the other way around that you want to protect against: unprivileged users influencing a "more privileged" domain.


Quote:
Originally Posted by shadowbox12 View Post
Feb 16 21:28:06 (null) (null): audit(1329449286.835:1394): avc: denied { open } for pid=9279 comm=ps name=stat ino=22259 dev=proc scontext=unconfined_u:unconfined_r:VirtualBox_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0 tclass=file
Feb 16 10:45:24 (null) (null): audit(1329410724.427:303): avc: denied { connectto } for pid=2876 comm=VirtualBox path=002F746D702F2E4943452D756E69782F32363138 scontext=unconfined_u:unconfined_r:VirtualBox_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=unix_stream_socket
It's odd the source domain runs in VirtualBox_t but as unconfined_u:unconfined_r:? I would have expected a service to run as system_u:system_r:VirtualBox_t...


Quote:
Originally Posted by shadowbox12 View Post
One thing I've noticed is a majority of the denials show "comm=ps" and "name=stat". These show up under a variety of contexts: syslogd_t, kernel_t, rpcbind_t, etc. I'm guessing Virtualbox is executing ps and piping the output through stat for some reason. Seems harmless enough, but I'm wondering if there is a simple way to allow this without having to create an allow rule for each different context it shows up under. Fix the root of the problem as it were.
Have to think about that.


Quote:
Originally Posted by shadowbox12 View Post
It looks like most of the {set*} permissions you suggested I look into relate to VirtualBox_t self:process. I'm not really clear on what that is about, but it seems fairly harmless to allow it modify itself. Is there something about this I should be paying attention to?
It would be good to know what it is about. For any set.* you could 'apropos {term}' to access documentation but beware that this works for say setsched or setrlimit but setcap is 'apropos capset'.

Last edited by unSpawn; 03-18-2012 at 10:56 AM.
 
Old 02-20-2012, 10:46 PM   #9
shadowbox12
Member
 
Registered: Mar 2010
Posts: 50

Original Poster
Rep: Reputation: 3
Quote:
Originally Posted by unSpawn View Post
Good decision. And TIA for sharing. When will you be posting it and where?
I'll post once I have something usable that works in enforcing mode. I'll probably post it here and on the virtualbox forums unless you have a better suggestion.


Quote:
Originally Posted by unSpawn View Post
Hmm. For me text relocation errors (== library developer mistakes) occur with libraries only, not binaries. If I 'grep -c textrel_shlib_t file_contexts.local' I get about 32 library entries for VLC, Google Earth, Firefox and a few other packages.
Yeah, the one I found is in a shared library, but the .so file is marked as executable.



Quote:
Originally Posted by unSpawn View Post
I'd rather you allow VirtualBox_t execmem as that confines things to that context. Setting the policy to "no audit" only means no warnings are generated. To put things in perspective if I 'sesearch -a|grep -c execmem' I get 200+ rules so while it's bad it's not like SELinux doesn't anticipate fixing this in the default targeted policy for a slew of domains including semanage_t and semanage_gui_t ;-p
Oh! That does put things into perspective. I guess SE Linux is still a work in progress then. I thought it was possible to set booleans for a specific domain, but if not then I agree the permission should be limited to the affected domain.

Since you agree creating a transition rule to bin_t is not advisable, what is the next best option? Create new contexts for grep and lsmod and then add transition rules for grep_t and lsmod_t?



Quote:
Originally Posted by unSpawn View Post
The default targeted policy basically hardens 'net-facing services, unprivileged users for instance run in the unconfined domain. For a "privileged" service to read or write to unconfined_t is not (or should not be) problematic, it's the other way around that you want to protect against: unprivileged users influencing a "more privileged" domain.
That's exactly the problem though. The unconfined domain is the *most* privileged domain because SELinux doesn't even try to restrain it. Any unconfined user logged in will have Gnome and all its processes running in unconfined_t, including a terminal shell running su or sudo.



Quote:
Originally Posted by unSpawn View Post
It's odd the source domain runs in VirtualBox_t but as unconfined_u:unconfined_r:? I would have expected a service to run as system_u:system_r:VirtualBox_t...
Ah, that's because the user I'm running with is an unconfined (non-root) user. I wanted to get the application restrictions working before I add user restrictions into the mix.

Here are some additional ps related virtualbox AVCs if that helps you figure anything out.

Feb 16 10:45:22 (null) (null): audit(1329410722.678:201): avc: denied { open } for pid=2882 comm=ps name=stat ino=13440 dev=proc scontext=unconfined_u:unconfined_r:VirtualBox_t:s0 tcontext=system_u:system_r:irqbalance_t:s0 tclass=file

Feb 16 10:45:22 (null) (null): audit(1329410722.680:217): avc: denied { read } for pid=2882 comm=ps name=stat ino=15429 dev=proc scontext=unconfined_u:unconfined_r:VirtualBox_t:s0 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tclass=file

Feb 16 10:45:22 (null) (null): audit(1329410722.681:233): avc: denied { search } for pid=2882 comm=ps name=2112 ino=15666 dev=proc scontext=unconfined_u:unconfined_r:VirtualBox_t:s0 tcontext=system_u:system_r:abrt_dump_oops_t:s0 tclass=dir

It looks like somewhere between 70-80% of the AVCs are related to ps with name=stat or name={pid}. I can't seem to figure out why either ps or stat would be running in another context though, much less in several.

Quote:
Originally Posted by unSpawn View Post
It would be good to know what it is about. For any set.* you could 'apropos {term}' to access documentation but beware that this works for say setsched or setrlimit but setcap is 'apropos capset'.
Ok, I looked into that. Setsched and setrlimit look pretty harmless. The most either could do is DOS my box. setgpid looks a little more dangerous if Virtualbox can assume the gpid of root or wheel or another privileged group. Setcap looks dangerous too, though the documentation is a little over my head. My plan is to start with just the safest, most obvious permissions first and see if Virtualbox will run in enforcing mode and if not slowly expand the allowances until it is able to function. It may be that it can run just fine without any of these.
 
Old 03-10-2012, 10:37 PM   #10
shadowbox12
Member
 
Registered: Mar 2010
Posts: 50

Original Poster
Rep: Reputation: 3
I've moved into the stage of setting the proto policy enforcing to watch how it breaks and add in rules one at a time until it works. Pretty early on I hit some snags where it would not even load the GUI without some rules I'm not comfortable with.

Without "allow VirtualBox_t bin_t:file { read execute open getattr execute_no_trans };" and
"allow VirtualBox_t bin_t:lnk_file read;" I get these errors:

/usr/bin/virtualbox: line 23: /sbin/lsmod: Permission denied
/usr/bin/virtualbox: line 23: /bin/grep: Permission denied
/usr/bin/virtualbox: line 24: /bin/uname: Permission denied
/usr/bin/virtualbox: line 24: /bin/cat: Permission denied
/usr/bin/virtualbox: line 53: /bin/grep: Permission denied
/usr/bin/virtualbox: line 53: /usr/bin/awk: Permission denied
/usr/bin/virtualbox: line 53: /usr/bin/whoami: Permission denied
/usr/bin/virtualbox: line 53: /bin/ps: Permission denied
/usr/bin/virtualbox: line 74: /bin/basename: Permission denied
Unknown application -

How can I deal with this without allowing virutalbox unrestricted access to /bin? I could change the labelling of only those files and grant access to them, but it seems that would probably screw up some other programs that expect those binaries to have the bin_t label.

Also I'm having trouble writing a transition rule. The /usr/bin/virtualbox file is actually just a link to /usr/bin/VBox. Both have the type VirtualBox_exec_t but for some reason I'm getting avc denials about execute_no_trans from source VirtualBox_t to target VirtualBox_exec_t. I created the following transition rule:
type_transition VirtualBox_t VirtualBox_exec_t:process VirtualBox_exec_t;
But without an allow execute_no_trans rule I get this error:
/usr/bin/virtualbox: line 77: /usr/lib/virtualbox/VirtualBox: Permission denied
/usr/bin/virtualbox: line 77: /usr/lib/virtualbox/VirtualBox: Permission denied

for which I show the following permissions:
-r-s--x--x. root root system_u:object_r:VirtualBox_exec_t:s0 /usr/lib/virtualbox/VirtualBox

I find the fact that all of these binaries are labelled VirtualBox_exec_t to be quite confusing.

Last edited by unSpawn; 03-11-2012 at 05:16 AM. Reason: //Added BB [noparse] tag
 
Old 03-11-2012, 05:25 AM   #11
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,518
Blog Entries: 51

Rep: Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598
Quote:
Originally Posted by shadowbox12 View Post
How can I deal with this without allowing virutalbox unrestricted access to /bin? I could change the labelling of only those files and grant access to them, but it seems that would probably screw up some other programs that expect those binaries to have the bin_t label.
Any domain including unconfined_t should have access to /bin by default: MAC works on top of DAC. So it's not like you're allowing VirtualBox_exec_t unrestricted access to /bin binaries.


Quote:
Originally Posted by shadowbox12 View Post
without an allow execute_no_trans rule I get this error:
/usr/bin/virtualbox: line 77: /usr/lib/virtualbox/VirtualBox: Permission denied
/usr/bin/virtualbox: line 77: /usr/lib/virtualbox/VirtualBox: Permission denied
In the past you've posted AVC messages. That's something we can work with. Please continue doing that.


BTW, was this fixed:
Quote:
Originally Posted by unSpawn View Post
Quote:
Originally Posted by shadowbox12 View Post
One thing I've noticed is a majority of the denials show "comm=ps" and "name=stat". These show up under a variety of contexts: syslogd_t, kernel_t, rpcbind_t, etc. I'm guessing Virtualbox is executing ps and piping the output through stat for some reason. Seems harmless enough, but I'm wondering if there is a simple way to allow this without having to create an allow rule for each different context it shows up under. Fix the root of the problem as it were.
Have to think about that.
If not post some actual AVC messages please.
 
Old 03-12-2012, 12:15 PM   #12
shadowbox12
Member
 
Registered: Mar 2010
Posts: 50

Original Poster
Rep: Reputation: 3
Quote:
Originally Posted by unSpawn View Post
Any domain including unconfined_t should have access to /bin by default: MAC works on top of DAC. So it's not like you're allowing VirtualBox_exec_t unrestricted access to /bin binaries.
Yes, I realize both MAC and DAC hurdles have to be cleared for access. I just felt there is no reason to grant MAC permissions to an entire directory if only a few files are used. Probably not worth the effort to fix though.

Quote:
Originally Posted by unSpawn View Post
In the past you've posted AVC messages. That's something we can work with. Please continue doing that.
The weird thing about the permission denied I get with the transition rule I wrote is that there are no AVC denials registered. At least nothing that looks remotely related. If I comment out the transition rule, but also don't allow execute_no_trans I get the same permission denied error, but I also get this AVC.

Mar 12 11:57:19 (null) (null): audit(1331571439.627:2035): avc: denied { execute_no_trans } for pid=3578 comm=virtualbox path="/usr/lib/virtualbox/VirtualBox" ino=3278667 dev=dm-1 scontext=unconfined_u:unconfined_r:VirtualBox_t:s0 tcontext=system_u:object_r:VirtualBox_exec_t:s0 tclass=file

I'm stumped on that one.

Quote:
Originally Posted by unSpawn View Post
BTW, was this fixed:

If not post some actual AVC messages please.
Sure, here's a few:

Feb 16 10:45:22 (null) (null): audit(1329410722.678:201): avc: denied { open } for pid=2882 comm=ps name=stat ino=13440 dev=proc scontext=unconfined_u:unconfined_r:VirtualBox_t:s0 tcontext=system_u:system_r:irqbalance_t:s0 tclass=file

Feb 16 10:45:22 (null) (null): audit(1329410722.680:217): avc: denied { read } for pid=2882 comm=ps name=stat ino=15429 dev=proc scontext=unconfined_u:unconfined_r:VirtualBox_t:s0 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tclass=file

Feb 16 10:45:22 (null) (null): audit(1329410722.681:233): avc: denied { search } for pid=2882 comm=ps name=2112 ino=15666 dev=proc scontext=unconfined_u:unconfined_r:VirtualBox_t:s0 tcontext=system_u:system_r:abrt_dump_oops_t:s0 tclass=dir

I posted a question about this to the virtualbox support forums last week, just asking what virtualbox is trying to do and why, but haven't gotten a response. The funny thing is, so far anyway, denying those permissions hasn't stopped virtualbox from running. I've managed to cobble together a list of the minimum permissions needed to get the basic GUI up, without attempting to load any VMs. A lot fewer permissions were required than I thought. Next step is to load VMs and exercise different aspects of functionality.

Last edited by unSpawn; 03-18-2012 at 10:57 AM.
 
Old 03-14-2012, 07:51 AM   #13
shadowbox12
Member
 
Registered: Mar 2010
Posts: 50

Original Poster
Rep: Reputation: 3
Well, I have cobbled together an ugly but functional policy at this point. The weird "ps" permissions were not required, so there's no point in losing sleep over that until the Oracle people can explain why that is important. I still need help with the transition rule from VirtualBox_t to VirtualBox_exec_t. Or is it ok to keep using the execute_no_trans as I have? Seems like things should run in the exec domain, but I'm not sure. Maybe it doesn't make any difference.

I've been trying to fine tune things, lock it down just little. I noticed there are a few virtualbox related files I've not accounted for showing up under /dev/vboxdrv /dev/vboxusb /dev/vboxnetctrl These have something to do with how virtualbox creates emulated hardware and maps it to real hardware. By default vboxdrv and vboxnetctrl get assigned to xserver_misc_device_t and vboxusb gets a mix of device_t and xserver_misc_device_t.

ls -alZ /dev/vboxusb/001
drwxr-x---. root vboxusers system_u:object_r:device_t:s0 .
drwxr-x---. root vboxusers system_u:object_r:device_t:s0 ..
crw-rw----. root vboxusers system_u:object_r:xserver_misc_device_t:s0 005

Since device_t is the default context for /dev lots of stuff has that which virtualbox probably doesn't need access to. I tried to create a new context called VirtualBox_device_t, but I really don't know what to do with that and the shell script refused to compile the policy module. Here's what I put in the te file:

type VirtualBox_device_t
files_type(VirtualBox_device_t)
allow VirtualBox_t VirtualBox_device_t:chr_file { read write open getattr };
manage_dirs_pattern(VirtualBox_t, VirtualBox_device_t, VirtualBox_device_t)
manage_files_pattern(VirtualBox_t, VirtualBox_device_t, VirtualBox_device_t)

and the fe file:
/dev/vboxusb(/.*)? gen_context(system_u:object_r:VirtualBox_device_t,s0)

When that didn't work, I assigned VirtualBox_rw_t to /dev/vboxusb and did a quick restorecon but that broke the USB functionality and yet generated no avc denials. When I changed the context back to its default everything worked fine again.

Last edited by unSpawn; 03-18-2012 at 10:55 AM. Reason: //Add BB noparse tags
 
Old 12-15-2012, 06:14 PM   #14
shadowbox12
Member
 
Registered: Mar 2010
Posts: 50

Original Poster
Rep: Reputation: 3
Well, my policy is as fine tuned as I can get it. I don't get any errors and can do everything I need it to do. People who want it to do different things may need to change settings, but I tried to comment it thoroughly. I did submit it to RedHat for comments/advice, but in 6+ months have heard no specific feedback other than its good but needs work. Thanks guys. Maybe someone else will find some value in this, so I'm releasing it here. Comments and improvements welcome.

Note: sometimes the /dev/vboxusb directory loses its defined context and requires a restorecon reset.
Attached Files
File Type: txt VirtualBox.fc.txt (5.5 KB, 9 views)
File Type: txt VirtualBox.te.txt (13.8 KB, 9 views)
 
1 members found this post helpful.
Old 12-15-2012, 06:38 PM   #15
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,518
Blog Entries: 51

Rep: Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598Reputation: 2598
Quote:
Originally Posted by shadowbox12 View Post
Well, my policy is as fine tuned as I can get it.
Thanks for posting back after about 9 months!


Quote:
Originally Posted by shadowbox12 View Post
Note: sometimes the /dev/vboxusb directory loses its defined context and requires a restorecon reset.
Shouldn't the 'restorecon' service take care of that?
 
  


Reply

Tags
selinux, virtualbox


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] reuse Selinux Policy rahulchandrak Linux - Security 11 09-02-2011 07:55 PM
Selinux-how do i find out what domains have permissions on what type?(selinux policy) vishyc88 Linux - Security 2 11-22-2010 04:27 AM
selinux restricting cvsweb from running hattori.hanzo Linux - Security 2 04-04-2008 01:04 AM
ncpfs selinux policy rhoekstra Linux - Security 2 10-17-2006 03:58 AM
restricting root with selinux wojtekjs Linux - Security 1 12-15-2005 10:00 PM


All times are GMT -5. The time now is 02:28 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration