Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #4431 > unrolled thread

Re: [SECURITY] [DSA 3405-1] smokeping security update

Back to article view | Back to linux.debian.security

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [SECURITY] [DSA 3405-1] smokeping security update Fredrik Kers <fredrik.kers@netrounds.com> - 2015-11-26 09:40 +0100
    Re: [SECURITY] [DSA 3405-1] smokeping security update Paul Wise <pabs@debian.org> - 2015-11-26 11:30 +0100
      Re: [SECURITY] [DSA 3405-1] smokeping security update Fredrik Kers <fredrik.kers@netrounds.com> - 2015-11-26 12:30 +0100
        Mandatory Access Control c4p0 <capo@riseup.net> - 2015-11-29 18:40 +0100
          Re: Mandatory Access Control Jason Fergus <leech@thefnords.org> - 2015-11-29 21:00 +0100
          Re: Mandatory Access Control Elmar Stellnberger <estellnb@gmail.com> - 2015-11-29 21:30 +0100
            Re: Mandatory Access Control Elmar Stellnberger <estellnb@gmail.com> - 2015-11-30 17:30 +0100
              Re: Mandatory Access Control Patrick Schleizer <adrelanos@riseup.net> - 2015-11-30 17:50 +0100
                Re: Mandatory Access Control Elmar Stellnberger <estellnb@gmail.com> - 2015-11-30 18:50 +0100
            Re: Mandatory Access Control Elmar Stellnberger <estellnb@gmail.com> - 2015-11-30 18:30 +0100
              Re: Mandatory Access Control Johannes Graumann <johannes.graumann@graumannschaft.org> - 2015-11-30 19:00 +0100

#4431 — Re: [SECURITY] [DSA 3405-1] smokeping security update

[Multipart message — attachments visible in raw view] — view raw

Not used

On Wed, Nov 25, 2015 at 10:27 PM, Florian Weimer <fw@deneb.enyo.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> - -------------------------------------------------------------------------
> Debian Security Advisory DSA-3405-1                   security@debian.org
> https://www.debian.org/security/                           Florian Weimer
> November 25, 2015                     https://www.debian.org/security/faq
> - -------------------------------------------------------------------------
>
> Package        : smokeping
> CVE ID         : CVE-2015-0859
>
> Tero Marttila discovered that the Debian packaging for smokeping
> installed it in such a way that the CGI implementation of Apache httpd
> (mod_cgi) passed additional arguments to the smokeping_cgi program,
> potentially leading to arbitrary code execution in response to crafted
> HTTP requests.
>
> For the oldstable distribution (wheezy), this problem has been fixed
> in version 2.6.8-2+deb7u1.
>
> For the stable distribution (jessie), this problem has been fixed in
> version 2.6.9-1+deb8u1.
>
> We recommend that you upgrade your smokeping packages.
>
> Further information about Debian Security Advisories, how to apply
> these updates to your system and frequently asked questions can be
> found at: https://www.debian.org/security/
>
> Mailing list: debian-security-announce@lists.debian.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJWVjDoAAoJEL97/wQC1SS+FyQH/2MqCMNWdWxgdaCEhVKsR5hE
> Yy7k7DxSuT6U9NhpqY3CggOCEySXayCNYHR0BtSbcxV6peEIjgN3+0cM601o1sU3
> SaOaJiTGWKYxCi2rFyZahGa5KT1xkKSDJKPqlTYaPFkO3EBFgCVAqX0O52QdlJfQ
> l9K7N7pCxh7tGQb7gnM3FwcPhGQz8R8dlirEGIt5lyd0Pwx1lgKVB9YpZQktwogD
> nmE9CxE16Fvhcn3yyQ2PKqflG/CmaBHIXxU4dzKjNT+FWz3ZH4AJlCueSwgyhmh0
> ET7IBRZ1cBeUS7CAk2z7UoRgNRFE5tbS3WfdmYlQe6olmL8nSd8sseNpTgahTgk=
> =AvSJ
> -----END PGP SIGNATURE-----
>
>


-- 

*Fredrik Kers* | CTO | linkedin.com/company/netrounds
<https://www.linkedin.com/company/netrounds>

<mats.nordlund@netrounds.com>

*Netrounds* | Storgatan 9 | 972 38 Luleå | Sweden | www.netrounds.com

[toc] | [next] | [standalone]

#4432

On Thu, Nov 26, 2015 at 4:16 PM, Fredrik Kers wrote:

> Not used

I'd suggest sending these emails to your co-workers at Netrounds
instead of to the debian-security mailing list.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#4433

[Multipart message — attachments visible in raw view] — view raw

That was the intention, but the reply button came in the way.

Will look more carefully where I click next time.

On Thu, Nov 26, 2015 at 11:26 AM, Paul Wise <pabs@debian.org> wrote:

> On Thu, Nov 26, 2015 at 4:16 PM, Fredrik Kers wrote:
>
> > Not used
>
> I'd suggest sending these emails to your co-workers at Netrounds
> instead of to the debian-security mailing list.
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>



-- 

*Fredrik Kers* | CTO | linkedin.com/company/netrounds
<https://www.linkedin.com/company/netrounds>

<mats.nordlund@netrounds.com>

*Netrounds* | Storgatan 9 | 972 38 Luleå | Sweden | www.netrounds.com

[toc] | [prev] | [next] | [standalone]

#4434 — Mandatory Access Control

[Multipart message — attachments visible in raw view] — view raw

I read the fucking manuals but don't have clear what is the better
option of "Mandatory Access Control" for debian jessie.
(AppArmor, SElinux, tomoyo, etc ..)

someone can give me your opinion about it?
thanks in advance


-- 
A5B4 7CDF 17BD E9AD 7A78 092E 53F4 DDB5 A091 CB3B

[toc] | [prev] | [next] | [standalone]

#4435 — Re: Mandatory Access Control

I think the problem lies in this "someone can give me your opinion about it?"  It's really all
opinion.  Each have their advantages and disadvantages.  Pretty sure most companies that would
require SElinux would also require RHEL/CentOS.  Debian simply gives you a choice of what you'd
prefer.  So if you really want to do it, look at each of them, and decide for yourself.  

On Sun, 2015-11-29 at 14:29 -0300, c4p0 wrote:
> I read the fucking manuals but don't have clear what is the better
> option of "Mandatory Access Control" for debian jessie.
> (AppArmor, SElinux, tomoyo, etc ..)
> 
> someone can give me your opinion about it?
> thanks in advance
> 
> 

[toc] | [prev] | [next] | [standalone]

#4436 — Re: Mandatory Access Control

SELinux is more elaborate and more complicated than Apparmor; tomoyo 
relatively new. I would personally regard none of those MAC systems as 
ultimate remedy to hard security problems. In 2011 I had a 
RedHat/SELinux system in its default configuration and it was 
compromised within minutes by simply viewing the page of my bank with a 
web browser (read the whole at: 
http://www.elstel.org/Censorship.html.en). Note that a single faulty 
system call in the Linux kernel may be used to obtain root rights 
leaving all additional security gains that MAC systems should deliver 
behind. Please note also that a system can not be secured without 
securing your X-server (formerly one could even paste text into any 
other window like a root console without being in need of root rights). 
Finally the security profiles of MAC systems are very complicated so 
that they would hardly deliver the security as possible in theory. If 
you wanna ask me for my security solution it is qemu based and puts the 
most vulnerable system components like browsers and email programs into 
a virtual machine namely qemu which is maintained by the Open Source 
commnunity.

Regards,
Elmar

On 29.11.2015 18:29, c4p0 wrote:
> I read the fucking manuals but don't have clear what is the better
> option of "Mandatory Access Control" for debian jessie.
> (AppArmor, SElinux, tomoyo, etc ..)
>
> someone can give me your opinion about it?
> thanks in advance
>
>

[toc] | [prev] | [next] | [standalone]

#4437 — Re: Mandatory Access Control

No actually it is not Qubes what I am using.
I am using full blown qemu virtualization including a virtual wrapper 
device for the graphics. It is for sure that even here the weakest point 
is the emulation of the graphics card. I have even heard about HTML5 
code directly bugging your hardware via graphics acceleration (though 
this is rather theoretical because it would likely need to be customized 
to a certain graphics card). Nonetheless the weakness of Qubes is even 
more the GUI dom where all other doms connect to and which has direct 
access to the graphics hardware. Unfortunately I could not find any 
details on how it is implemented in deed.
Additionally I found it somewhat irritating that the basic description 
of the Qubes project talks so much about using Windows as a host. I 
would never trust software which is entirely closed source. Please do 
also note the following statement found in the intro when considering to 
use Qubes:
"Sure, a single kernel exploit destroys this all"

If you remember what I have told you about MAC systems then it was that 
a single public accessible system call which is implemented faulty would 
still compromise your system. Now consider that all current operating 
systems including Windows, Linux and FreeBSD are huge monolitic 
constructs making use of just two privilege levels/ security rings: user 
and kernel mode. At the introduction of the i386 (which is now still 
long ago) Intel suggested that at least three privilege levels would be 
necessary to build a secure system: the innermost for memory and process 
management, a middle ring for device and hardware drivers and the 
outermost one for user space programs. According to my knowledge and to 
what is public none of the operating system developers have followed 
these precautions until today (Xen is a different case as it uses three 
rings but not in the way as described above; actually it would need to 
make use of all four rings provided by the protected mode interface to 
be secure in theory - Nonetheless just believe me that things are not as 
theoretical in practice as this description may make you believe.).

Regards,
Elmar

On 29.11.2015 22:05, Patrick Schleizer wrote:
> Elmar Stellnberger:
>> If you wanna ask me for my security solution it is qemu based and puts
>> the most vulnerable system components like browsers and email programs
>> into a virtual machine namely qemu which is maintained by the Open
>> Source commnunity.
>
> Sounds like Qubes.
>
> Cheers,
> Patrick
>

[toc] | [prev] | [next] | [standalone]

#4438 — Re: Mandatory Access Control

Qubes is based on Xen. There are templates for Fedora, Debian and others.

Windows can be a guest VM. Windows as a host is only a theoretical
consideration for a theoretical port. [Hypervisor Abstraction Layer (HAL)]

What convinced me of Qubes is, that for Linux a single explorable wifi
driver is enough to already own everything, while with Qubes this code
runs in a dedicated NetVM.

For implementation details, see this pdf.
https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf

It has a chapter "Secure GUI".

Elmar Stellnberger:
> No actually it is not Qubes what I am using.
> I am using full blown qemu virtualization including a virtual wrapper
> device for the graphics. It is for sure that even here the weakest point
> is the emulation of the graphics card. I have even heard about HTML5
> code directly bugging your hardware via graphics acceleration (though
> this is rather theoretical because it would likely need to be customized
> to a certain graphics card). Nonetheless the weakness of Qubes is even
> more the GUI dom where all other doms connect to and which has direct
> access to the graphics hardware. Unfortunately I could not find any
> details on how it is implemented in deed.
> Additionally I found it somewhat irritating that the basic description
> of the Qubes project talks so much about using Windows as a host. I
> would never trust software which is entirely closed source. Please do
> also note the following statement found in the intro when considering to
> use Qubes:
> "Sure, a single kernel exploit destroys this all"
> 
> If you remember what I have told you about MAC systems then it was that
> a single public accessible system call which is implemented faulty would
> still compromise your system. Now consider that all current operating
> systems including Windows, Linux and FreeBSD are huge monolitic
> constructs making use of just two privilege levels/ security rings: user
> and kernel mode. At the introduction of the i386 (which is now still
> long ago) Intel suggested that at least three privilege levels would be
> necessary to build a secure system: the innermost for memory and process
> management, a middle ring for device and hardware drivers and the
> outermost one for user space programs. According to my knowledge and to
> what is public none of the operating system developers have followed
> these precautions until today (Xen is a different case as it uses three
> rings but not in the way as described above; actually it would need to
> make use of all four rings provided by the protected mode interface to
> be secure in theory - Nonetheless just believe me that things are not as
> theoretical in practice as this description may make you believe.).
> 
> Regards,
> Elmar
> 
> On 29.11.2015 22:05, Patrick Schleizer wrote:
>> Elmar Stellnberger:
>>> If you wanna ask me for my security solution it is qemu based and puts
>>> the most vulnerable system components like browsers and email programs
>>> into a virtual machine namely qemu which is maintained by the Open
>>> Source commnunity.
>>
>> Sounds like Qubes.
>>
>> Cheers,
>> Patrick
>>
> 

[toc] | [prev] | [next] | [standalone]

#4440 — Re: Mandatory Access Control

I know. The question here is how the Qubes clients connect to the 
Xen-GUI-dom (Concerning Windows I am just annoyed about that many 
indirect promotion for a closed source host system when it comes to 
security issues). Separating the Wifi/WLAN driver may be a good point 
though.

Elmar

P.S.: I would have nothing against a Windows guest (as you have 
suggested). However there was also some suggestion about using it as 
host in the Qubes introduction:
 > These are known as “Type 2” or “hosted” hypervisors. These programs
 > are popular because they’re designed  primarily to be easy to use and
 > run under popular OSes like Windows ...


On 30.11.2015 17:48, Patrick Schleizer wrote:
> Qubes is based on Xen. There are templates for Fedora, Debian and others.
>
> Windows can be a guest VM. Windows as a host is only a theoretical
> consideration for a theoretical port. [Hypervisor Abstraction Layer (HAL)]
>
> What convinced me of Qubes is, that for Linux a single explorable wifi
> driver is enough to already own everything, while with Qubes this code
> runs in a dedicated NetVM.
>
> For implementation details, see this pdf.
> https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf
>
> It has a chapter "Secure GUI".
>
> Elmar Stellnberger:
>> No actually it is not Qubes what I am using.
>> I am using full blown qemu virtualization including a virtual wrapper
>> device for the graphics. It is for sure that even here the weakest point
>> is the emulation of the graphics card. I have even heard about HTML5
>> code directly bugging your hardware via graphics acceleration (though
>> this is rather theoretical because it would likely need to be customized
>> to a certain graphics card). Nonetheless the weakness of Qubes is even
>> more the GUI dom where all other doms connect to and which has direct
>> access to the graphics hardware. Unfortunately I could not find any
>> details on how it is implemented in deed.
>> Additionally I found it somewhat irritating that the basic description
>> of the Qubes project talks so much about using Windows as a host. I
>> would never trust software which is entirely closed source. Please do
>> also note the following statement found in the intro when considering to
>> use Qubes:
>> "Sure, a single kernel exploit destroys this all"
>>
>> If you remember what I have told you about MAC systems then it was that
>> a single public accessible system call which is implemented faulty would
>> still compromise your system. Now consider that all current operating
>> systems including Windows, Linux and FreeBSD are huge monolitic
>> constructs making use of just two privilege levels/ security rings: user
>> and kernel mode. At the introduction of the i386 (which is now still
>> long ago) Intel suggested that at least three privilege levels would be
>> necessary to build a secure system: the innermost for memory and process
>> management, a middle ring for device and hardware drivers and the
>> outermost one for user space programs. According to my knowledge and to
>> what is public none of the operating system developers have followed
>> these precautions until today (Xen is a different case as it uses three
>> rings but not in the way as described above; actually it would need to
>> make use of all four rings provided by the protected mode interface to
>> be secure in theory - Nonetheless just believe me that things are not as
>> theoretical in practice as this description may make you believe.).
>>
>> Regards,
>> Elmar
>>
>> On 29.11.2015 22:05, Patrick Schleizer wrote:
>>> Elmar Stellnberger:
>>>> If you wanna ask me for my security solution it is qemu based and puts
>>>> the most vulnerable system components like browsers and email programs
>>>> into a virtual machine namely qemu which is maintained by the Open
>>>> Source commnunity.
>>>
>>> Sounds like Qubes.
>>>
>>> Cheers,
>>> Patrick
>>>
>>
>

[toc] | [prev] | [next] | [standalone]

#4439 — Re: Mandatory Access Control

Dear Henriette,

Yes, I am using qemu-kvm based virtualization. According to my 
experience that was sufficient to protect the host from the guest. The 
most vulnerable part will be the graphics output as I have already said. 
Nonetheless I did also receive the many messages about vulnerabilities 
in the Wifi stack. Gonna have to tell that I do only have practical 
experience with qemu-kvm/ethernet. You can use a mobile wifi router 
through which you plug in your ethernet port (or wait for and trust in 
the fixes). Separating the Wifi driver in its own Xen-domain would of 
course be another solution as long as all graphcis output still becomes 
filtered by emulating a virtual graphics card/device.

Best Elmar


On 29.11.2015 22:31, Henriette wrote:
> Hey Elmar,
>
> I was looking into using virtualization for security purposes too. However I
> refrained from using a full grown vbox installation so far.
>
> I saw that qemu provides a user-mode virtualization. I could imagine that this
> brings already some security if you are able to specify access only to certain
> directories etc. However I couldn't find any info with some quick google
> searches on how to use qemu to improve systems security by virt. Are you using
> this mode to get some security or is there no way around a full virtualization
> to improve security?
>
> Best Henriette
>
> Am Sun, 29 Nov 2015 21:26:41 +0100
> schrieb Elmar Stellnberger <estellnb@gmail.com>:
>
>> SELinux is more elaborate and more complicated than Apparmor; tomoyo
>> relatively new. I would personally regard none of those MAC systems as
>> ultimate remedy to hard security problems. In 2011 I had a
>> RedHat/SELinux system in its default configuration and it was
>> compromised within minutes by simply viewing the page of my bank with a
>> web browser (read the whole at:
>> http://www.elstel.org/Censorship.html.en). Note that a single faulty
>> system call in the Linux kernel may be used to obtain root rights
>> leaving all additional security gains that MAC systems should deliver
>> behind. Please note also that a system can not be secured without
>> securing your X-server (formerly one could even paste text into any
>> other window like a root console without being in need of root rights).
>> Finally the security profiles of MAC systems are very complicated so
>> that they would hardly deliver the security as possible in theory. If
>> you wanna ask me for my security solution it is qemu based and puts the
>> most vulnerable system components like browsers and email programs into
>> a virtual machine namely qemu which is maintained by the Open Source
>> commnunity.
>>
>> Regards,
>> Elmar
>>
>> On 29.11.2015 18:29, c4p0 wrote:
>>> I read the fucking manuals but don't have clear what is the better
>>> option of "Mandatory Access Control" for debian jessie.
>>> (AppArmor, SElinux, tomoyo, etc ..)
>>>
>>> someone can give me your opinion about it?
>>> thanks in advance
>>>
>>>
>>
>

[toc] | [prev] | [next] | [standalone]

#4441 — Re: Mandatory Access Control

[Multipart message — attachments visible in raw view] — view raw

Elmar,

Do you have documentation of your labours available?

Sincerely, Joh

On Monday 30 November 2015 18:20:00 Elmar Stellnberger wrote:
> Dear Henriette,
> 
> Yes, I am using qemu-kvm based virtualization. According to my
> experience that was sufficient to protect the host from the guest. The
> most vulnerable part will be the graphics output as I have already said.
> Nonetheless I did also receive the many messages about vulnerabilities
> in the Wifi stack. Gonna have to tell that I do only have practical
> experience with qemu-kvm/ethernet. You can use a mobile wifi router
> through which you plug in your ethernet port (or wait for and trust in
> the fixes). Separating the Wifi driver in its own Xen-domain would of
> course be another solution as long as all graphcis output still becomes
> filtered by emulating a virtual graphics card/device.
> 
> Best Elmar
> 
> On 29.11.2015 22:31, Henriette wrote:
> > Hey Elmar,
> > 
> > I was looking into using virtualization for security purposes too. 
However
> > I refrained from using a full grown vbox installation so far.
> > 
> > I saw that qemu provides a user-mode virtualization. I could imagine 
that
> > this brings already some security if you are able to specify access only
> > to certain directories etc. However I couldn't find any info with some
> > quick google searches on how to use qemu to improve systems 
security by
> > virt. Are you using this mode to get some security or is there no way
> > around a full virtualization to improve security?
> > 
> > Best Henriette
> > 
> > Am Sun, 29 Nov 2015 21:26:41 +0100
> > 
> > schrieb Elmar Stellnberger <estellnb@gmail.com>:
> >> SELinux is more elaborate and more complicated than Apparmor; 
tomoyo
> >> relatively new. I would personally regard none of those MAC systems 
as
> >> ultimate remedy to hard security problems. In 2011 I had a
> >> RedHat/SELinux system in its default configuration and it was
> >> compromised within minutes by simply viewing the page of my bank 
with a
> >> web browser (read the whole at:
> >> http://www.elstel.org/Censorship.html.en). Note that a single faulty
> >> system call in the Linux kernel may be used to obtain root rights
> >> leaving all additional security gains that MAC systems should deliver
> >> behind. Please note also that a system can not be secured without
> >> securing your X-server (formerly one could even paste text into any
> >> other window like a root console without being in need of root 
rights).
> >> Finally the security profiles of MAC systems are very complicated so
> >> that they would hardly deliver the security as possible in theory. If
> >> you wanna ask me for my security solution it is qemu based and 
puts the
> >> most vulnerable system components like browsers and email 
programs into
> >> a virtual machine namely qemu which is maintained by the Open 
Source
> >> commnunity.
> >> 
> >> Regards,
> >> Elmar
> >> 
> >> On 29.11.2015 18:29, c4p0 wrote:
> >>> I read the fucking manuals but don't have clear what is the better
> >>> option of "Mandatory Access Control" for debian jessie.
> >>> (AppArmor, SElinux, tomoyo, etc ..)
> >>> 
> >>> someone can give me your opinion about it?
> >>> thanks in advance

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web