RE: [SECURITY] [DSA 2460-1] asterisk security update
Har du sett denna? Original Message From: Moritz MuehlenhoffSent: Wed, 25/04/2012 18:06 To: debian-security-annou...@lists.debian.org CC: Subject: [SECURITY] [DSA 2460-1] asterisk security update-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2460-1 secur...@debian.org http://www.debian.org/security/Moritz Muehlenhoff April 25, 2012 http://www.debian.org/security/faq - - Package: asterisk Vulnerability : several Problem type : remote Debian-specific: no CVE ID : CVE-2012-1183 CVE-2012-2414 CVE-2012-2415 Several vulnerabilities were discovered in the Asterisk PBX and telephony toolkit: CVE-2012-1183 Russell Bryant discovered a buffer overflow in the Milliwatt application. CVE-2012-2414 David Woolley discovered a privilege escalation in the Asterisk manager interface. CVE-2012-2415 Russell Bryant discovered a buffer overflow in the Skinny driver. For the stable distribution (squeeze), this problem has been fixed in version 1:1.6.2.9-2+squeeze5. For the unstable distribution (sid), this problem will be fixed soon. We recommend that you upgrade your asterisk packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk+YIOUACgkQXm3vHE4uylpTYQCeIlkGimI8WtcdKK6oYD09ckfm dDUAnjksH+0jJLCG7ioSnb81645CJe5c =0126 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120425160640.GA6420@pisco.westfalen.local
Re: About audit2allow generated rules
HI Russell thanks a lot. that is really helpful. just wondering where is the tclass=sock_file defined? basically i have apache mod_tile want to access /var/run/renderd/renderd.sock ( from renderd) ls -lZ /var/run/renderd/ -rw-r--r--. apache apache system_u:object_r:initrc_var_run_t:s0 renderd.pid srwxrwxrwx. apache apache system_u:object_r:var_run_t:s0 renderd.sock -rw-r--r--. apache apache system_u:object_r:initrc_var_run_t:s0 renderd.stats how can I change /define tclass=sock_file to something like tclass=renderd_sock_file? or change /var/run/renderd/renderd.sock to some something like: var_run_renderd_t? what I want to do is just granting the permission that is needed? or generally is there a simple way to how to define/write a policy that only give the needed permission ( there are some howto seems still complicated??) ? not just rely on aduit2allow to do the magic blindly? min On 04/26/2012 12:00 AM, Russell Coker wrote: On Thu, 26 Apr 2012, Min Wangser.ba...@gmail.com wrote: I have something in /var/log/audit/audit.log like: avc: denied { write } for pid=23739 comm=httpd name=renderd.sock dev=dm-0 ino=1183752 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file use audit2allow it generates something like this: allow httpd_t var_run_t:sock_file write; Is the rule too liberal? that means httpd_t can write any var_run_t 's sock_file? Or I miss-understand something? Ideally there should be no sock_file objects with type var_run_t, every Unix domain socket should have a type which is derived from the domain of the process which creates it. So having one such socket is an indication of your configuration not being ideal. If you only have one daemon with policy that allows such sockets then it's probably not a big deal to grant access to httpd_t. Think of var_run_t being similar to the nobody UID in this case. Having exactly one daemon running as nobody theoretically isn't a security problem, but having two daemons running with that UID probably is. The problem is that people tend not to stop at one, if they have one daemon running in that manner then they may end up with two (through a repeat of the same choices) - so it's best to stick with zero! -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f996fcc.2090...@gmail.com
Message de Benjamin MABILLE / CCA
Bonjour, J'ai bien recu votre message, je suis actuellement en conges et je serai de retour le Mardi 15 mai 2012. En mon absence, vous pouvez contacter notre standard au 0826 80 80 80 ou le service technique a l'adresse techni...@intracall.com Cordialement, CCA International Benjamin MABILLE Développeur 42-46 rue Riolan 80 000 Amiens - France tel. +33 3 22 82 02 57 www.ccainternational.com -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/yu0qbbxhovuz62w.260420122...@mail.intracall.com
Re: About audit2allow generated rules
On Fri, 27 Apr 2012, Min Wang ser.ba...@gmail.com wrote: just wondering where is the tclass=sock_file defined? In the refpolicy source it is in policy/flask/access_vectors . basically i have apache mod_tile want to access /var/run/renderd/renderd.sock ( from renderd) ls -lZ /var/run/renderd/ -rw-r--r--. apache apache system_u:object_r:initrc_var_run_t:s0 renderd.pid srwxrwxrwx. apache apache system_u:object_r:var_run_t:s0 renderd.sock -rw-r--r--. apache apache system_u:object_r:initrc_var_run_t:s0 renderd.stats how can I change /define tclass=sock_file sock_file is the class of the object, other classes include file and dir. These are not things you change, these are human readable names for things that are part of the OS. What you want to do is to have the daemon run as renderd_t and use renderd_var_run_t as the type for the socket fike. what I want to do is just granting the permission that is needed? or generally is there a simple way to how to define/write a policy that only give the needed permission ( there are some howto seems still complicated??) ? not just rely on aduit2allow to do the magic blindly? As I said before, you can just grant that access and and it will work. But if the renderd is running as root then it is a security risk (I guess that renderd is running as initrc_t or unconfined_t and is not being restricted by SE Linux). Even if renderd is not given excessive privs then it's not ideal to allow httpd_t access to sock_file:var_run_t due to the possibility of other daemons being able to create such objects. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201204271147.28959.russ...@coker.com.au