Re: Zoneminder and Selinux and the Infinite Story of Doom
by Tristan Santore
On 21/05/13 14:58, m.roth(a)5-cent.us wrote:
> Tristan Santore wrote:
>> Dear All,
>>
>> For the last few days Dominick and I have been trying to write a policy
>> for Zoneminder, as the current policy does not seem to be working.
>>
>> I will append what we gathered up so far below, however before I do,
>> there seems to be an inherent problem with apache and sudo/su/pam, which
>> seems to work in permissive mode, but as soon as I enable enforcing,
>> b00m, I get these.
>>
>> May 21 14:18:23 hq su: pam_unix(su:auth): auth could not identify
>> password for [apache]
>> May 21 14:18:23 hq su: pam_succeed_if(su:auth): requirement "uid >=
>> 1000" not met by user "apache"
>> May 21 14:18:23 hq su: pam_unix(su:auth): auth could not identify
>> password for [apache]
>> May 21 14:18:23 hq su: pam_succeed_if(su:auth): requirement "uid >=
>> 1000" not met by user "apache"
> <snip>
> I'm nowhere near that good with selinux, but
> a) the apache or httpd user normally has a GID under 1000 - that's the way
> it's installed. It is a system daemon.
> b) looks like something with apache wants a password. Is this a
> self-signed secure site that you gave it a password when you created the
> cert, so that it needs one to start up?
>
> mark
>
I think it has more to do with the fact it is looking for a file or
something with information in, probably relating to sudo/pam.
And because there is some protection in selinux somewhere, maybe even in
Apache itself (although unlikely as it works in permissive mode), it
gets stuck, and we are not seeing any useful denials .
Zoneminder has a web front-end, some binaries, and they need to access
/dev/video nodes. So that appears to be the reason why it uses sudo as
some kind of protection. But I have not looked into it too much.
There are quite a few scripts, some binaries. Bit of a jumble yard.
With regards to certs....no certs.
Regards,
Tristan
--
Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile +44-78-55069812
Tristan.Santore(a)internexusconnect.net
Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)
For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org
10 years, 11 months
openswan start denied by selinux if a custom log file is used
by Manuel Wolfshant
Hello
I am using CentOS 6.4 and I want to store the logs from openswan
into a different file ( /var/log/ipsec ) than the default. For this
purpose I added
plutostderrlog=/var/log/ipsec
to ipsec.conf.
As long as I keep the server in permissive mode, openswan starts
OK. If, however, I switch to enforcing, the daemon refuses to start with
the following error message displayed in the console:
ipsec_setup: Starting Openswan IPsec
U2.6.32/K3.0.78-1.el6.elrepo.x86_64...
ipsec_setup: Cannot write to "/var/log/ipsec".
The audit log does not record anything useful so I tried to switch
dontaudit to off and see if anything useful comes out. After running
audit2allow and a bit of trial and error I came out with the following
custom policy :
module myipsec 1.0;
require {
type ipsec_t;
type var_log_t;
class file { write ioctl getattr append };
}
#============= ipsec_mgmt_t ==============
allow ipsec_mgmt_t var_log_t:file write;
The above policy worked for me but I am wondering if it is OK (I am
mostly confused by the fact that the class includes " write ioctl
getattr append " but the rule has only "write" ). And, assuming it is OK
can this custom policy ( or the corrected one if needed ) be included in
the default policy ?
TIA
manuel
10 years, 11 months
Proof is in the pudding
by Douglas Brown
Hi all,
You may have seen this vulnerability talked about recently: http://arstechnica.com/security/2013/05/critical-linux-vulnerability-impe...
After a long time of evangelising about SELinux to my sceptical colleagues, this seemed like the perfect opportunity to test it.
We tried the exploit with SELinux in permissive mode and it worked then in enforcing and SELinux prevented it! Not that I'm surprised, but it's nice to have a real-world exploit to demonstrate.
Cheers,
Doug
10 years, 11 months
NFS boolaens Fedora 18
by Frank Murphy
I can no longer find what booleans,
(the used appear in "Selinux-Manager" GUI)
may be needed on an nfs client to work (if any)
with the files on an nfs server
on the server I did:
nfs_export_all_rw 1
Am trying to use a shared: /var/cache/yum (on the server)
selinux-policy-targeted-3.11.1-92.fc18.noarch (Clients)
policycoreutils-gui-2.1.13-59.fc18.x86_64 (Clients)
Have looked at:
https://fedoraproject.org/wiki/SELinux/rpcd
--
Regards,
Frank - I check for new mail app. 20min
www.frankly3d.com
10 years, 11 months
Reg. Best Practices for User ids
by Ramkumar Raghavan
Hi,
Please let me know how the selinux operations varies with user id's
greater than 500 and those with uid's less than 500.
We are planning to configure uid's for application users for our custom
applications. What is the best practice to make these applications
secure.
Thanks
Ramkumar Raghavan
10 years, 11 months
question why newrole gives error
by John Emrich
Hello,
Running Fedora-18. When executing the newrole command I consistently get the same error message "incorrect password for xyzuser". I have su'd to root. Everything appears valid. Below is a snippet from a terminal session that demonstrates the error message. I receive the same error regardless whether I am in enforcement mode or not. Any suggestions as to the cause?
[root@localhost xyzuser]# newrole -r system_r -t sysadm_t
Password:
newrole: incorrect password for xyzuser
Error sending audit message.
[root@localhost xyzuser]# semanage user -l
Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range SELinux Roles
... deleted lines
...
root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
sysadm_u user s0 s0-s0:c0.c1023 sysadm_r
system_u user s0 s0-s0:c0.c1023 system_r unconfined_r
unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r
... deleted lines
...
[root@localhost xyzuser]# id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Thank You
John Emrich
10 years, 12 months
NFS Home Directory Files Mis-Labelled
by Mike Pinkerton
[Note: I sent this message yesterday without first subscribing to
the list -- intending to check the web archive for responses.
Because my message has not yet shown up in the web archive, I
subscribed in order to re-send this. My apologies if both messages
make it out of the moderation queue.]
Last summer, I set up a network with about a dozen stationary boxes
and 15-20 moveable users. All users are authenticating via FreeIPA,
and have their home directories NFS-mounted from a central file
server. Both the desktop boxes and the file server were running
Fedora 16.
+ User home directories were mounted from "/srv/exports/<user_name>".
+ The desktop boxes had SE Linux boolean "use_nfs_home_dirs=1".
+ The file server had "/etc/selinux/targeted/contexts/files/
file_contexts.local" with:
/srv system_u:object_r:home_root_t:s0
All was working well.
In March, I upgraded all of the desktop boxes, as well as the file
server and the FreeIPA server to Fedora 18.
+ User home directories are still mounted from "/srv/exports/
<user_name>".
+ The desktop boxes still have SE Linux boolean "use_nfs_home_dirs=1".
+ The file server still has "/etc/selinux/targeted/contexts/files/
file_contexts.local" with:
/srv system_u:object_r:home_root_t:s0
The problems is that, as some users create files, they are being
created with context:
"system_u:object_r:user_home_t:s0"
rather than:
"unconfined_u:object_r:user_home_t:s0"
If I run "restorecon -FR /srv" , then the files are re-labelled to
the "unconfined_u".
I don't know how frequently files are created with the wrong context.
Any ideas as to what is happening?
Thanks.
--
Mike
10 years, 12 months
I need a script invoked from procmail_t to run unconfined.
by Robert Nichols
I have a script invoked from a procmail recipe that needs to perform
actions involving searching for processes by name, playing sound through
pulseaudio, sending mail, plus a few others. When I run with enforcing=0
I get 385 AVC denials (103KB, not attached), and that's _without_
disabling the "dontaudit" rules, which would yield over 100 more
denials. The target contexts are not something I can change without
totally destroying the current policy.
Any suggestions other than the 120 "allow" rules that audit2allow would
suggest (and that's without considering the "dontaudit" denials)?
I'm getting _really_ tired of this. I'm spending more time trying to
get things to work under SELinux than it would take me to recover from a
(highly unlikely) intrusion. Sometimes the cost of insurance is just
too high.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
10 years, 12 months
Disable policy module?
by Moray Henderson
Is there a way to disable a particular module in
selinux-policy-targeted-3.7.19-195.el6_4.1.noarch.rpm without having to
modify and rebuild the whole RPM?
Our versions of Ruby and Passenger put things in different places than the
ones expected by the SELinux passenger module so we've had to remove it and
make our own. That meant we missed a RHEL 6.4 selinux-policy update and
ended up with a broken Samba 3.6. If there's a way we can go back to using
the standard selinux-policy rpms but disable the passenger module, it would
be very useful.
Thanks,
Moray.
"To err is human; to purr, feline."
10 years, 12 months
why qemu can access mnt_t type
by bigclouds
hi,all
why qemu can access mnt_t type dirs. following is my ls command, qemu use a file which has MCS, but its parent dirs is not virt_image_t type.
under what condition this will happen? i do nothing about selinux policy.
thanks
[root@www data-center]# ls -lZ /rhev/data-center/25c47fdd-47a3-4eac-933a-70ea6d44f615/5dad0fa9-a924-48e5-b248-9b58bd9ac986/images/149ec5e4-45e0-4353-bfa6-58ba9ed9c888/486a26e1-79f7-4df2-9469-c48613741c7e
-rw-rw----. qemu kvm system_u:object_r:svirt_image_t:s0:c517,c988 /rhev/data-center/25c47fdd-47a3-4eac-933a-70ea6d44f615/5dad0fa9-a924-48e5-b248-9b58bd9ac986/images/149ec5e4-45e0-4353-bfa6-58ba9ed9c888/486a26e1-79f7-4df2-9469-c48613741c7e
[root@www data-center]# ls -lZ /rhev/data-center
drwxr-xr-x.qemu kvm unconfined_u:object_r:mnt_t:s0 25c47fdd-47a3-4eac-933a-70ea6d44f615
drwxr-xr-x. qemu kvm system_u:object_r:mnt_t:s0 mnt
[root@www data-center]# ls -lZ /rhev/data-center/25c47fdd-47a3-4eac-933a-70ea6d44f615/
lrwxrwxrwx. qemu kvm unconfined_u:object_r:mnt_t:s0 5dad0fa9-a924-48e5-b248-9b58bd9ac986 -> /rhev/data-center/mnt/_home_kvm_vms/5dad0fa9-a924-48e5-b248-9b58bd9ac986
[root@www data-center]# ls -lZ /rhev/data-center/25c47fdd-47a3-4eac-933a-70ea6d44f615/5dad0fa9-a924-48e5-b248-9b58bd9ac986/
drwxr-xr-x. qemu kvm system_u:object_r:user_home_t:s0 images
10 years, 12 months
