RE: [SECURITY] [DSA 2460-1] asterisk security update

[Josef]

Har du sett denna? Original Message  From: Moritz Muehlenhoff  Sent: 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

[Min Wang]

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

[Mabille Benjamin]

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

[Russell Coker]

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