AppArmor or SELinux?

06-17-2012, 03:46 PM

On Sun, 17 Jun 2012 13:14:03 +0200, Claudius Hubig wrote:

> I am running Testing/Sid amd64 with Multi-Arch enabled (i. e. Acrobat
> Reader and Skype from i386) on a single-user machine and hereâ€™s what I
> want to achieve:
>
> - Programs that process data â€˜from the internetâ€™ are only allowed to
> access the files they strictly need to access, plus a $HOME/Desktop
> (to share files with other such processes etc.)
> - The same restrictions apply to childs of these processes - All other
> processes are allowed to do whatever their standard Unix
> permissions allow them to do.
>
> In the past, I achieved this via AppArmor and custom profiles for
> Pidgin, Opera, Iceweasel and Skype[1,2].

I remember AppArmor was installed and ready-to-use in openSUSE, but to be
sincere, I never bothered in enabling the profiles nor using them: too
much hassle for a little gain.

And I share the same feeling for SELinux, I mean, a tool that can be very
helpful when it is properly configured and you know well about its
possibilities but its setting up is not what we would consider a child
game.

> However, I just noticed that there donâ€™t appear AppArmor profiles to be
> around for Kernel 3.3 or 3.4, and, aside from that, only Ubuntu appears
> to use it, while SELinux is much more common. A bit more reading in the
> Debian Handbook then illustrated that SELinux is apparently more
> powerful but also more complex than AppArmor.

Debian used to include some support for SELinux but I dunno about the
status for AppArmor. There's more information here:

http://wiki.apparmor.net/index.php/Distro_debian

AppArmor was firstly developed and maintained by Novell but IIRC it was
Ubuntu who finally "took the control" (read it as "lead its development")
over the project.

> My question is: Would it make sense to deploy SELinux on my system to
> achieve the tasks mentioned above?

Mmm... I'd say no.

> I know that security cannot be absolute, but I would feel much more
> comfortable if an exploit in the MSN handler of Pidgin or a plugin gone
> wild in Opera wouldnâ€™t make my private SSH keys accessible to the world
> :-)

I find it a valid concern but for a mere user point of view, I would
prefer having to deal with not that complex utilities to harden the
system applications, for example, something like the sandbox or virtual
machine concept, i.e., easy to deploy (some brosers already include a
sandbox from where they run the dangerous plugins), easy to understand (a
separate zone that cannot interefere with the host system) and easy to use
("run & go", or "install, run & go") :-)

Greetings,

--
CamaleÃ³n

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/jrku56$f0n$16@dough.gmane.org

06-17-2012, 04:00 PM

Hahaha

women are more careful then men are.

Perhaps CamaleÃ³n (as I) does know Suse

. And IIRC Suse first ships
with AppAmor.

Sorry, who exactly plans a conspiracy? Regarding to the answer AppArmor
might be helpful, if not, it just spam shutdown messages with crap, as
it does for my self-build kernels.

Joe and Sam (most wanted spammers on this list) never ever will have
impact to your Linux

. Forget AppArmor! Read about ConsoleKit and
other "security helpers", we already run much to much threads, when
running Linux.

2Â²Cents,
Ralf

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1339948825.2074.49.camel@precise

Sun Jun 17 18:30:01 2012
Return-Path: <infrastructure-bounces@lists.fedoraproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
eagle542.startdedicated.com
X-Spam-Level:
X-Spam-Status: No, score=-2.2 required=5.0 tests=DKIM_ADSP_CUSTOM_MED,
DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNS WL_MED,T_DKIM_INVALID,
T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: tom@linux-archive.org
Delivered-To: tom-linux-archive.org@eagle542.startdedicated.com
Received: from bastion.fedoraproject.org (bastion01.fedoraproject.org [209.132.181.2])
by eagle542.startdedicated.com (Postfix) with ESMTP id 752E020E0373
for <tom@linux-archive.org>; Sun, 17 Jun 2012 18:05:52 +0200 (CEST)
Received: from lists.fedoraproject.org (collab03.vpn.fedoraproject.org [192.168.1.70])
by bastion01.phx2.fedoraproject.org (Postfix) with ESMTP id 0325121376;
Sun, 17 Jun 2012 16:05:51 +0000 (UTC)
Received: from collab03.fedoraproject.org (localhost [127.0.0.1])
by lists.fedoraproject.org (Postfix) with ESMTP id B992040B17;
Sun, 17 Jun 2012 16:05:50 +0000 (UTC)
X-Original-To: infrastructure@lists.fedoraproject.org
Delivered-To: infrastructure@lists.fedoraproject.org
Received: from smtp-mm03.fedoraproject.org (vm4.fedora.ibiblio.org
[152.19.134.143])
by lists.fedoraproject.org (Postfix) with ESMTP id EF5B940ACB
for <infrastructure@lists.fedoraproject.org>;
Sun, 17 Jun 2012 16:05:48 +0000 (UTC)
Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com
[209.85.160.45])
by smtp-mm03.fedoraproject.org (Postfix) with ESMTP id 4211F406E1
for <infrastructure@lists.fedoraproject.org>;
Sun, 17 Jun 2012 16:05:48 +0000 (UTC)
Received: by pbbro12 with SMTP id ro12so7681694pbb.32
for <infrastructure@lists.fedoraproject.org>;
Sun, 17 Jun 2012 09:05:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s 120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:content-type; bh=cgn9HcDLDt+ognnHHawhQaBWGV0IMseSJzJqAczm80s=;
b=apiVJK/TK7iugcg944KtX51puvvr+K/JJmY2sYUgAYaUfYMArUyG7jqVn1KFIzqTYM
sRGd1sGyUbLB5VpKI27hFBzJWDiCvBLfZSbbi5E56EOZkNgPIn neZsHLumQw5Km/6HnE
qNW8mjLDLduEyMfXsMhNSVGaDor+x/x3uidGNGMNW2j1ReWCs3JyOhRVf+6Y4Wr3eOxx
t6DFFEbkHblsi76hXkzT6ANmMqbIkih7BXloIl1OfWMMTL4KY3 HpOV5qcbzHDWT2UF/R
51p6JdvxM0Uxuo5VnxhmPXZxke5RKkBqmaS24AorgghwZJabf6 uCWRSnUCd89iVAN9GH
mqow=Received: by 10.68.191.106 with SMTP id gx10mr41433063pbc.37.1339949147355;
Sun, 17 Jun 2012 09:05:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.227.74 with HTTP; Sun, 17 Jun 2012 09:05:27 -0700 (PDT)
In-Reply-To: <CAOLy5tZ5zvLfwW_gu7Nz6Rvzp5Hxwu6WOhkiLN9ksWehLyKD ZA@mail.gmail.com>
References: <6DA95E08-4600-4CBB-BEB4-75B102AFD697@gmail.com>
<20120614104304.6092a5e6@jelerak.scrye.com>
<4FDA15D5.5020105@gmail.com>
<20120615155728.565dd581@jelerak.scrye.com>
<CAOLy5tZ5zvLfwW_gu7Nz6Rvzp5Hxwu6WOhkiLN9ksWehLyKD ZA@mail.gmail.com>
From: =?UTF-8?B?0KHRgtCw0L3QuNGB0LvQsNCyINCl0LDQvdC20LjQvQ==? <hanzhin.stas@gmail.com>
Date: Sun, 17 Jun 2012 20:05:27 +0400
Message-ID: <CAAFrROCmUVDjC9QkogNdTSfU=4QKHjHQuw9VY_EzC9gS+ohc jw@mail.gmail.com>
Subject: Re: Dynamic Nagios Configuration
To: Fedora Infrastructure <infrastructure@lists.fedoraproject.org>
X-BeenThere: infrastructure@lists.fedoraproject.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Fedora Infrastructure <infrastructure@lists.fedoraproject.org>
List-Id: Fedora Infrastructure <infrastructure.lists.fedoraproject.org>
List-Unsubscribe: <https://admin.fedoraproject.org/mailman/options/infrastructure>,
<mailto:infrastructure-request@lists.fedoraproject.org?subject=unsubscrib e>
List-Archive: <http://lists.fedoraproject.org/pipermail/infrastructure/>
List-Post: <mailto:infrastructure@lists.fedoraproject.org>
List-Help: <mailto:infrastructure-request@lists.fedoraproject.org?subject=help>
List-Subscribe: <https://admin.fedoraproject.org/mailman/listinfo/infrastructure>,
<mailto:infrastructure-request@lists.fedoraproject.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="==============U13559310726345066=="
Sender: infrastructure-bounces@lists.fedoraproject.org
Errors-To: infrastructure-bounces@lists.fedoraproject.org

--==============U13559310726345066=Content-Type: multipart/alternative; boundaryï¿½8fb2088cf1f9fd04c2ad3814

--e89a8fb2088cf1f9fd04c2ad3814
Content-Type: text/plain; charset=UTF-8

Kevin, the real job there is to construct good SELinux policy for check_mk
serverside. Clients are already packaged.

2012/6/16 yancy ribbens <yancy.ribbens@gmail.com>

> Another great tool for Nagios config management is NagiosQL. Config files
> are stored and managed using PHP and MYSQL, and then written to Nagios
> config files on demand.
>
> http://exchange.nagios.org/directory/Addons/Configuration/NagiosQL/details
>
> -Yancy
>
> On Fri, Jun 15, 2012 at 4:57 PM, Kevin Fenzi <kevin@scrye.com> wrote:
>
>> On Thu, 14 Jun 2012 20:48:21 +0400
>> Stanislav Hanzhin <hanzhin.stas@gmail.com> wrote:
>>
>> > Hi all,
>> > Why don't you use check_mk as nagios config generator?
>> >
>> > I use it in production on CentOS for almost 2 years and I can name it
>> > a great solution for monitoring automation.
>> >
>> > For further info see: http://mathias-kettner.de/check_mk.html
>>
>> It's been suggested before.

>>
>> It sounds interesting, but the first hurdle is that we need someone to
>> package it up and get it into EPEL.
>>
>> I'd be happy to help in efforts to do this...
>>
>> kevin
>>
>> _______________________________________________
>> infrastructure mailing list
>> infrastructure@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>>
>
>
> _______________________________________________
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>

--e89a8fb2088cf1f9fd04c2ad3814
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Kevin, the real job there is to construct good SELinux policy for check_mk serverside. Clients are already packaged.<br><br><div class="gmail_quote">2012/6/16 yancy ribbens <span dir="ltr"><<a href="mailto:yancy.ribbens@gmail.com" target="_blank">yancy.ribbens@gmail.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Another great tool for Nagios configÂ*managementÂ*is NagiosQL. Â*Config files are stored and managed using PHP and MYSQL, and thenÂ*writtenÂ*to Nagios config files on demand.<br>

<br><a href="http://exchange.nagios.org/directory/Addons/Configuration/NagiosQL/details" target="_blank">http://exchange.nagios.org/directory/Addons/Configuration/NagiosQL/details</a><span class="HOEnZb"><font color="#888888"><div>

<br></div><div>-Yancy</div></font></span><div><br><div class="gmail_quote"><div><div class="h5">On Fri, Jun 15, 2012 at 4:57 PM, Kevin Fenzi <span dir="ltr"><<a href="mailto:kevin@scrye.com" target="_blank">kevin@scrye.com</a>></span> wrote:<br>

</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<div>On Thu, 14 Jun 2012 20:48:21 +0400<br>
Stanislav Hanzhin <<a href="mailto:hanzhin.stas@gmail.com" target="_blank">hanzhin.stas@gmail.com</a>> wrote:<br>
<br>
> Hi all,<br>
> Why don't you use check_mk as nagios config generator?<br>
><br>
> I use it in production on CentOS for almost 2 years and I can name it<br>
> a great solution for monitoring automation.<br>
><br>
> For further info see: <a href="http://mathias-kettner.de/check_mk.html" target="_blank">http://mathias-kettner.de/check_mk.html</a><br>
<br>
</div>It's been suggested before.

<br>
<br>
It sounds interesting, but the first hurdle is that we need someone to<br>
package it up and get it into EPEL.<br>
<br>
I'd be happy to help in efforts to do this...<br>
<span><font color="#888888"><br>
kevin<br>
</font></span><br></div></div><div class="im">_______________________________________ ________<br>
infrastructure mailing list<br>
<a href="mailto:infrastructure@lists.fedoraproject.or g" target="_blank">infrastructure@lists.fedoraproject .org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/infrastructure" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/infrastructure</a><br></div></blockquote></div><br></div>
<br>______________________________________________ _<br>
infrastructure mailing list<br>
<a href="mailto:infrastructure@lists.fedoraproject.or g">infrastructure@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/infrastructure" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/infrastructure</a><br></blockquote></div><br><br clear="all"><div><br></div><br>

--e89a8fb2088cf1f9fd04c2ad3814--

--==============U13559310726345066=Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX18KaW5mcmFzdHJ1
Y3R1cmUgbWFpbGluZyBsaXN0CmluZnJhc3RydWN0dXJlQGxpc3 RzLmZlZG9yYXByb2plY3Qub3Jn
Cmh0dHBzOi8vYWRtaW4uZmVkb3JhcHJvamVjdC5vcmcvbWFpbG 1hbi9saXN0aW5mby9pbmZyYXN0
cnVjdHVyZQ=
--==============U13559310726345066==--

06-17-2012, 04:38 PM

On Sun 17 Jun 2012 at 18:00:25 +0200, Ralf Mardorf wrote:

[Snip]

> Joe and Sam (most wanted spammers on this list) never ever will have
> impact to your Linux

. Forget AppArmor! Read about ConsoleKit and
> other "security helpers", we already run much to much threads, when
> running Linux.

Consolekit is not a replacement for AppArmor; they have different
purposes. Cannot comment on "security helpers" because its function is
unknown.

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120617163818.GE30016@desktop

06-17-2012, 04:41 PM

Hello CamaleÃ³n,

CamaleÃ³n <noelamac@gmail.com> wrote:
> On Sun, 17 Jun 2012 13:14:03 +0200, Claudius Hubig wrote:
> And I share the same feeling for SELinux, I mean, a tool that can be very
> helpful when it is properly configured and you know well about its
> possibilities but its setting up is not what we would consider a child
> game.

Administrating a computer is not a child game, and, yes, it took me
some time to tweak my custom AppArmor profiles to do what I want.

> > However, I just noticed that there donâ€™t appear AppArmor profiles to be
^^^^^^^^
This should read â€˜patchesâ€™. IOW, the kernel patches distributed with
AppArmor currently donâ€™t apply cleanly to Kernel 3.4 sources.

> Debian used to include some support for SELinux but I dunno about the
> status for AppArmor. There's more information here:
>
> http://wiki.apparmor.net/index.php/Distro_debian

Unfortunately, that information is rather out of date, as you can see
from the Kernel version numbers, for example. That said, AppArmor
currently runs fine on Linux 3.2 - and I just found what appears to
be kernel 3.4 patches[1]. Nevertheless, my concerns still stand, as
the development model of AppArmor still appears rather chaotic, with
some outdated wiki pages etc.

> > My question is: Would it make sense to deploy SELinux on my system to
> > achieve the tasks mentioned above?
>
> Mmm... I'd say no.

Thanks. Please allow me to rephrase the question:
Given the temporary unavailability of kernel patches for AppArmor for
kernel 3.4, the fact that it appears not to be fully merged into the
main kernel, the rather chaotic wiki page which lets one hunt for the
required patches and the lack of official support by major
distributions other than Ubuntu, would it make sense to switch from a
running AppArmor system to a SELinux system?

> I find it a valid concern but for a mere user point of view, I would
> prefer having to deal with not that complex utilities to harden the
> system applications, for example, something like the sandbox or virtual
> machine concept, i.e., easy to deploy (some brosers already include a
> sandbox from where they run the dangerous plugins), easy to understand (a
> separate zone that cannot interefere with the host system) and easy to use
> ("run & go", or "install, run & go") :-)

Security can never be reached by a run & go concept, simply because
individual requirements differ far too much to cater for all
different needs with default configurations. And while sandboxing is
a sensible approach _within_ the browser, it only handles plugins in
an assumed-as-safe application, not the application itself.
The kernel should do that, and thatâ€™s what SELinux, AppArmor etc. are
for, in my opinion: separate processes, users and files as much as
possible.

Complete virtual machines for each of the applications (Opera,
Iceweasel, Pidgin, Skype) would
a) probably break my machineâ€™s RAM requirements
b) be rather unusable
c) make it much more difficult to, for example, download a file with
Iceweasel and then send it to someone using Pidgin.

Best regards,

Claudius

[1] http://wiki.apparmor.net/index.php/Gittutorial
--
A wife lasts only for the length of the marriage, but an ex-wife is
there *for the rest of your life*.
-- Jim Samuels
http://chubig.net telnet nightfall.org 4242

06-17-2012, 04:45 PM

Hello Ralf,

Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
> Sorry, who exactly plans a conspiracy?

Err, what?

> Regarding to the answer AppArmor
> might be helpful, if not, it just spam shutdown messages with crap, as
> it does for my self-build kernels.

It works quite nicely over here.

> Joe and Sam (most wanted spammers on this list) never ever will have
> impact to your Linux

.

So what? I donâ€™t plan to use AppArmor/SELinux as a spam filter, I
donâ€™t think you read my original email.

> Forget AppArmor! Read about ConsoleKit and
> other "security helpers", we already run much to much threads, when
> running Linux.

a) ConsoleKit allows non-root users to access various files/devices
to which they otherwise wouldnâ€™t have access. To say the least, it
does the exact opposite of MAC system.
b) I donâ€™t know what other security helpers youâ€™re referring to.
Would you mind to expand on that?
c) I shall think about your advice to forget AppArmor and then,
logically and in line with my original question, deploy SELinux.
d) AppArmor doesnâ€™t add a single thread to a running Linux system.

Best regards,

Claudius
--
"... an experienced, industrious, ambitious, and often quite often
picturesque liar."
-- Mark Twain
http://chubig.net telnet nightfall.org 4242

06-17-2012, 04:45 PM

On Sun, 2012-06-17 at 17:38 +0100, Brian wrote:
> On Sun 17 Jun 2012 at 18:00:25 +0200, Ralf Mardorf wrote:
>
> [Snip]
>
> > Joe and Sam (most wanted spammers on this list) never ever will have
> > impact to your Linux

. Forget AppArmor! Read about ConsoleKit and
> > other "security helpers", we already run much to much threads, when
> > running Linux.
>
> Consolekit is not a replacement for AppArmor; they have different
> purposes. Cannot comment on "security helpers" because its function is
> unknown.

Yes, but it's part of the paranoia

and comes withs tons of threads,
on Ubuntu Precise:

spinymouse@precise:~$ ps -eLf|grep console-kit-daemon|wc -l
66

Won't reboot to Debian now.

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1339951546.2074.59.camel@precise

06-17-2012, 04:52 PM

On Sun, 2012-06-17 at 18:45 +0200, Claudius Hubig wrote:
> AppArmor doesnâ€™t add a single thread to a running Linux system.

So it's a voodoo-ghost and doesn't need resources?

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1339951972.2074.61.camel@precise

06-17-2012, 05:17 PM

PS:

Regarding to ConsoleKit, POSIX threads?

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1339953435.2074.65.camel@precise

06-17-2012, 06:05 PM

On Sun, 17 Jun 2012 18:41:22 +0200, Claudius Hubig wrote:

> CamaleÃ³n <noelamac@gmail.com> wrote:
>> On Sun, 17 Jun 2012 13:14:03 +0200, Claudius Hubig wrote: And I share
>> the same feeling for SELinux, I mean, a tool that can be very helpful
>> when it is properly configured and you know well about its
>> possibilities but its setting up is not what we would consider a child
>> game.
>
> Administrating a computer is not a child game, and, yes, it took me some
> time to tweak my custom AppArmor profiles to do what I want.

You say "administrating", users say "playing" :-)

If I put the admin hat on, I can understand what you mean, what I wanted
to say is that plain users do not usually care for that things.

>> Debian used to include some support for SELinux but I dunno about the
>> status for AppArmor. There's more information here:
>>
>> http://wiki.apparmor.net/index.php/Distro_debian
>
> Unfortunately, that information is rather out of date, as you can see
> from the Kernel version numbers, for example.

"Out of date"... don't say that word to a person who is using kernel
2.6.26 :-P. Now seriously, the wiki talks about kernel 3.1, and that's
not that old.

> That said, AppArmor currently runs fine on Linux 3.2 - and I just found
> what appears to be kernel 3.4 patches[1]. Nevertheless, my concerns
> still stand, as the development model of AppArmor still appears rather
> chaotic, with some outdated wiki pages etc.

AppArmor was included in the mainline kernel tree time ago and I have not
read about it was removed or something like that, so it has to be still
supported for the newer versions :-?

>> > My question is: Would it make sense to deploy SELinux on my system to
>> > achieve the tasks mentioned above?
>>
>> Mmm... I'd say no.
>
> Thanks. Please allow me to rephrase the question: Given the temporary
> unavailability of kernel patches for AppArmor for kernel 3.4, the fact
> that it appears not to be fully merged into the main kernel, the rather
> chaotic wiki page which lets one hunt for the required patches and the
> lack of official support by major distributions other than Ubuntu, would
> it make sense to switch from a running AppArmor system to a SELinux
> system?

I'd say "no" again :-)

As I already mentioned, both approaches look too complex to my taste.

Anyway, if what you are telling me is that should you have to go with
AppArmor or SELinux (yes or yes), of course I'd choose SELinux in Debian.
But if there's not a hard requirement and the system is going to be used
for general purpose, I'd install/configure none of them.

>> I find it a valid concern but for a mere user point of view, I would
>> prefer having to deal with not that complex utilities to harden the
>> system applications, for example, something like the sandbox or virtual
>> machine concept, i.e., easy to deploy (some brosers already include a
>> sandbox from where they run the dangerous plugins), easy to understand
>> (a separate zone that cannot interefere with the host system) and easy
>> to use ("run & go", or "install, run & go") :-)
>
> Security can never be reached by a run & go concept, simply because
> individual requirements differ far too much to cater for all different
> needs with default configurations.

Well, if the provided solution is well implemented, why not? That's what
most of us have been doing all this time before VM were widely deployed;
isolated machines for different purposes with no network connection to
avoid 95% of the security flaws.

> And while sandboxing is a sensible approach _within_ the browser, it
> only handles plugins in an assumed-as-safe application, not the
> application itself.

Yes, it was just a sample concept, nothing you can use for your problem.

> The kernel should do that, and thatâ€™s what SELinux, AppArmor etc. are
> for, in my opinion: separate processes, users and files as much as
> possible.

Yes, but again, the price to pay to have those apps properly configured
so they can be of really uselfulness is too high, IMO.

> Complete virtual machines for each of the applications (Opera,
> Iceweasel, Pidgin, Skype) would
> a) probably break my machineâ€™s RAM requirements
> b) be rather unusable
> c) make it much more difficult to, for example, download a file with
> Iceweasel and then send it to someone using Pidgin.

Yes, I know. But again, I was pointing to the browser sandbox and VM as
another way to handle some aspects of your security concerns but to all,
I mean, a VM will not prevent your browser passwords or cookies can be
stolen but can indeed avoid your host files to be accessed.

Greetings,

--
CamaleÃ³n

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/jrl68o$f0n$18@dough.gmane.org

06-17-2012, 07:30 PM

On Sun, Jun 17, 2012 at 12:45 PM, Ralf Mardorf
<ralf.mardorf@alice-dsl.net> wrote:
> On Sun, 2012-06-17 at 17:38 +0100, Brian wrote:
>> On Sun 17 Jun 2012 at 18:00:25 +0200, Ralf Mardorf wrote:
>>>
>>> Joe and Sam (most wanted spammers on this list) never ever will have
>>> impact to your Linux

. Forget AppArmor! Read about ConsoleKit and
>>> other "security helpers", we already run much to much threads, when
>>> running Linux.
>>
>> Consolekit is not a replacement for AppArmor; they have different
>> purposes. Cannot comment on "security helpers" because its function is
>> unknown.
>
> Yes, but it's part of the paranoia

and comes withs tons of threads,
> on Ubuntu Precise:
>
> spinymouse@precise:~$ ps -eLf|grep console-kit-daemon|wc -l
> 66

It's an old bug/feature:

https://bugs.freedesktop.org/show_bug.cgi?id=17720

Patches were proposed then pulled because they had undesirable side-effects.

Take a look at the last post in the bug report above and then at:

http://www.freedesktop.org/wiki/Software/ConsoleKit

--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAOdo=SzKF4KqMb8j97YXH18e5cC29TiNqOq-okm6WHtrCDyOXQ@mail.gmail.com