Bug 541657
| Summary: | SELinux is preventing /usr/sbin/asterisk "getcap" access. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Wolfgang Rupprecht <wolfgang.rupprecht> | ||||||
| Component: | asterisk | Assignee: | Jeffrey C. Ollie <jeff> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 12 | CC: | amessina, bsexton, dwalsh, itamar, jeff, kgagnon, maarten, mgrepl, michal | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | setroubleshoot_trace_hash:a184567fe87c4f9dfeee8ad643c0606af68037dc554525ac4d85e96e6be35013 | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2010-12-04 02:44:49 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Wolfgang Rupprecht
2009-11-26 16:21:00 UTC
This was a result of normal asterisk startup after a reboot. *** Bug 541728 has been marked as a duplicate of this bug. *** Created attachment 374596 [details]
"avc" messages collected by asterisk
This is not only 'setcap' or 'getcap'. For all practical purposes selinux on Fedora 12 breaks asterisk quite thoroughly. After an upgrade of an asterisk server machine from Fedora 10, where it was running for quite a while with selinux in an "Enforcing" mode and no complaints in logs, I immediately started collecting entries like attached and had to switch to "Permissive". Both for F10 and F11 policies were "targeted"
That is an excerpt. A number of "avc" complaints about asterisk is steadily growing.
Michal I will add allow rules for most of this, but I would rather not allow asterisk to write to the /root directory. Why is it doing this? Fixed in selinux-policy-3.6.32-52.fc12.noarch Asterisk is not very careful with respect to security. There are plenty of system(2) calls with uncleaned arguments. I really don't trust it, and trust it even less to write into /. I'm glad to hear you aren't going to allow the write. In this case it may well be that asterisk is trying to write into a history file that it keeps at /.asterisk_history . # ll -a / total 146 dr-xr-xr-x. 35 root root 4096 2009-11-28 03:12 . dr-xr-xr-x. 35 root root 4096 2009-11-28 03:12 .. -rw-------. 1 root root 13 2009-11-30 03:07 .asterisk_history -rw-r--r--. 1 root root 0 2009-11-28 03:11 .autofsck drwxr-xr-x. 4 root root 4096 2009-02-28 23:49 backup ... $ echo ~asterisk /var/lib/asterisk Now, I have no idea why it doesn't keep it in its own home directory. I suppose I should start filing bugs against asterisk. BTW. I'm not seeing any operational errors for asterisk even when selinux is enforcing. The logs are noisy, but that seems to be the only effect for me. Daniel, see my response in BZ#542839 for why Asterisk is trying to write to '/'. Was there something changed between selinux-policy-3.6.32-46 and -49 in regards to Asterisk? I've not run into any SELinux-related issues regarding Asterisk on F-12 but I'm still running the older selinux-policy package. > ... but I would rather not allow
> asterisk to write to the /root directory. Why is it doing this?
Frankly I have no idea. I was not even aware that it can as that process is owned by an 'asterisk' id and that has /sbin/nologin for a shell. OK, I see that something wrote /.asterisk_history and /root/.asterisk_history. These files
are not exactly readable. Something of that sort:
_HiStOrY_V2_
exit\134134134134134134134134134134134134134134012\1341....
That is on a specialized asterisk server which really does nothing else. OTOH its "well-beeing" is kind of critical to owners so I am somewhat reluctant to hack too much around it.
Other than that I cannot find any traces.
Michal, actually, it's probably not the main Asterisk process that is writing the files, it's any commands that use '/usr/sbin/asterisk -r' to connect to the CLI. That process runs as root. Re comment #8: > ... it's probably not the main Asterisk process that is writing I think that you are right. Still I wonder what wrote /.asterisk_history. Not very much in it. Just one line "_HiStOrY_V2_" and a timestamp suggesting some cron job. My best guess would be that this was logrotate which runs "/usr/sbin/asterisk -rx 'logger reload'". Would setting here HOME be of help? Still apart from attempts to write /root/.asterisk_history, which would come from 'asterisk -r' while trying to debug a configuration, I do not see any other instances of scribbling over /root/ in this log excerpt I attached. There is quite a few of reads from /dev/urandom and few other things but elsewhere. Yes can asterisk set the HOME to /var/lib/asterisk for its logrotate script. Probably a better idea to use /usr/share/asterisk for HOME in logrotate as /var/lib/asterisk seems to be on its way out. I guess that I can file here an asterisk bug report but this still leaves interactive runs of 'asterisk -r' as somewhat problematic. Would be helpful for 'asterisk' package to touch /root/.asterisk in %post to make a place for an appropriate label? Obviously selinux policies would have to be aware of that. "/usr/share/asterisk" should be read-only for Asterisk (on Fedora at least). Asterisk should be writing most of it's stuff to "/var/spool/asterisk". "/var/lib/asterisk" is currently listed as the home user for Asterisk, I'll keep that around for writing the .asterisk_history and other cruft like that. See also bug 542839. I don't care about the admin running asterisk, only system processes like init or system cron. They should use the location of the asterisk homedir. An administrator running asterisk will stay as unconfined_t and be able to write to the /root directory. While using selinux-policy-3.6.32-55.fc12 from updates testing I still see some of avc messages like illustrated in an attachment 374596 [details]. audit2allow produces for these:
#============= asterisk_t ==============
allow asterisk_t postgresql_port_t:tcp_socket name_connect;
allow asterisk_t self:process getsched;
and audit2why comes with "Missing type enforcement (TE) allow rule". Yeah, I guess so.
Any idea why it is connecting to posgresql? You can add these rules for now using # grep avc /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Fixed in selinux-policy-3.6.32-57.fc12.noarch (In reply to comment #17) > Any idea why it is connecting to posgresql? Asterisk has an optional module for accessing information stored in a PostgreSQL database. 57 will allow it. I looked it up after I asked. Dan, asterisk has a homegrown programming language (reminiscent of sendmail's nonsense.) One use of this language is to allow the asterisk admin to rewrite data, such as fill in the caller-id names for calls that come in with caller-id numbers only. This number->name data can be stored in a database that asterisk links to or I guess calls externally now. Created attachment 381430 [details]
audit complaints generated by logrotate with mods for asterisk
In /etc/logrotate.d/asterisk I tried
HOME=/var/lib/asterisk \
/usr/sbin/asterisk -rx 'logger reload' ....
That indeed wrote /var/lib/asterisk/.asterisk_history, with "Permissive" for selinux, but also produced an audit spill like the one attached.
As there is nothing of interest in this .asterisk_history I think that I will replace the above with
HOME=/var/tmp \
/usr/sbin/asterisk -rx 'logger reload' ....
Hopefuly this should be enough.
You can add these rules for now using # grep avc /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Fixed in selinux-policy-3.6.32-66.fc12.noarch I think the /.asterisk_history file is written by the init script, when it checks if there is already an asterisk version running:
VERSION=`${AST_SBIN}/asterisk -rx 'core show version'`
(Line 73 of /etc/init.d/asterisk).
This command is now run as root and maybe should run as the asterisk user.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |