Re: [arch-general] ofono install

[Peter Nabbefeld]

Am 02.02.2017 um 07:05 schrieb Eli Schwartz via arch-general:

On 02/02/2017 12:08 AM, Peter Nabbefeld wrote:

I'm using pacaur, as it seems to be the easiest way to install AUR packages.


And pacaur notices that the maintainer did something wrong, panics, and
aborts on you. pacaur actually uses the metadata from the .SRCINFO to
track what exists where, and packages which violate that expectation
confuse its parser.

It is entirely possible the built package exists in the cache somewhere.

In the meantime, I've managed to use makepkg --noextract --install on 
the cached files after editing .SRCINFO to reflect the correct version 
id. So I've got a running oFono 1.19 installation now, which will not be 
upgraded before oFono 1.20 is out.


Regards
P.

[arch-general] How to run ofono as backend for a headset?

[Peter Nabbefeld]

Hello,

due to 
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index35h3 
I should get HSP/HFP support using ofono as a backend and setting 
headset="ofono", but it doesn't work.


I've already started ofono using "systemctl restart ofono" and 
started/stopped pulseaudio, but it displays "HSP/HFP unavailable".


Is there any documentation about how to connect a bluetooth headset 
using ofono?


Kind regards
Peter

Re: [arch-general] ofono install

[Eli Schwartz via arch-general]

On 02/02/2017 12:08 AM, Peter Nabbefeld wrote:
> I'm using pacaur, as it seems to be the easiest way to install AUR packages.

And pacaur notices that the maintainer did something wrong, panics, and
aborts on you. pacaur actually uses the metadata from the .SRCINFO to
track what exists where, and packages which violate that expectation
confuse its parser.

It is entirely possible the built package exists in the cache somewhere.

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] ofono install

[Peter Nabbefeld]

Am 02.02.2017 um 00:28 schrieb ProgAndy:

Am 01.02.2017 um 23:06 schrieb Peter Nabbefeld:


Hello,

I tried to install ofono from AUR, because I want HSP/HFP support for
pulseaudio
(https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index35h3),
but I get an error about a conflict between .SRCINFO and PKGBUILD -
how can I resolve this problem?

Kind regards
Peter


That sounds like you are using an AUR helper that compares the contents
of the PKGBUILD to the .SRCINFO file that provides the display data for
the AUR entry. The ofono maintainer only updated the PKGBUILD to 1.19
forgot to regenerate the SRCINFO (it still shows 1.18).

In this case you should build the package manually using makepkg and at
most a simple download helper like cower.


--

Andreas


I'm using pacaur, as it seems to be the easiest way to install AUR packages.

Peter

Re: [arch-general] ofono install

[Peter Nabbefeld]

Am 01.02.2017 um 23:52 schrieb Maxwell Anselm via arch-general:


I get an error about a conflict between .SRCINFO and PKGBUILD - how can I
resolve this problem?



I'm not getting that error, have you tried cloning a fresh copy from AUR?
Regardless, you don't need to care about .SRCINFO unless you're the
maintainer. Just delete it.

Max

I looked into these two files - version of .SRCINFO is 1.18, while in 
PKGBUILD it is 1.19. Seems as if You have the "original" 1.18 build, 
which is not updated because of unchanged .SRCINFO, so no conflicts.


As I'm installing the updated package, PKGBUILD loads version 1.19 of 
ofono, which conflicts with .SRCINFO.


Peter

Re: [arch-general] user namespaces

[Doug Newgard]

On Thu, 2 Feb 2017 05:13:46 +0100
sivmu  wrote:

> Am 02.02.2017 um 05:10 schrieb Maxwell Anselm via arch-general:
> >>
> >> All those distros, everyone except arch has decided at some point to no
> >> longer restrict the use of unprivileged user namespaces.
> >>  
> > 
> > In no way whatsoever does Arch restrict the use of unprivileged user
> > namespaces. Rebuilding your kernel with them enabled is a trivial task for
> > any user familiar with ABS. If you feel this strongly about it please write
> > a wiki article about the benefits/tradeoffs and link it with the relevant
> > application articles (Firejail, Security, etc.).
> > 
> > Max
> >   
> 
> This issue is about the default arch kernel disabling user namespaces
> and the consequence that many applications have to use insecure
> workarounds like suid to still work on arch.
> 
> This has nothing to do with the gernal ability to user user namespaces
> on arch, this is about the default kernel.
> 

You have said multiple times that Arch is restricting this. They're not. It's
simply not there by default, like just about everything in Arch. Build your own
kernel and move on.


pgppTsH5wnbTm.pgp
Description: OpenPGP digital signature

Re: [arch-general] user namespaces

[sivmu]

Am 02.02.2017 um 05:10 schrieb Maxwell Anselm via arch-general:
>>
>> All those distros, everyone except arch has decided at some point to no
>> longer restrict the use of unprivileged user namespaces.
>>
> 
> In no way whatsoever does Arch restrict the use of unprivileged user
> namespaces. Rebuilding your kernel with them enabled is a trivial task for
> any user familiar with ABS. If you feel this strongly about it please write
> a wiki article about the benefits/tradeoffs and link it with the relevant
> application articles (Firejail, Security, etc.).
> 
> Max
> 

This issue is about the default arch kernel disabling user namespaces
and the consequence that many applications have to use insecure
workarounds like suid to still work on arch.

This has nothing to do with the gernal ability to user user namespaces
on arch, this is about the default kernel.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] user namespaces

[Maxwell Anselm via arch-general]

>
> All those distros, everyone except arch has decided at some point to no
> longer restrict the use of unprivileged user namespaces.
>

In no way whatsoever does Arch restrict the use of unprivileged user
namespaces. Rebuilding your kernel with them enabled is a trivial task for
any user familiar with ABS. If you feel this strongly about it please write
a wiki article about the benefits/tradeoffs and link it with the relevant
application articles (Firejail, Security, etc.).

Max

Re: [arch-general] sandboxing

[sivmu]

-- Changed the topic to keep things clean --


Am 01.02.2017 um 21:16 schrieb Leonid Isaev:
> 
> But you see, sandboxing apps is by itself is a misleading security feature. 
> Why
> do I need to sandbox my browser if it is written properly and allows me to
> disable the unnecessary (for me) features?
> 

Sorry to say this, but this is the most disturbingly naive thing I have
read in quite some time.


As a rule, it is said that programms contain one error for every 1000
lines of code.

Firefox contains 14 million lines of code
Chromium has 15,3 million lines

Do the math


No matter how much you focus on secure coding, there will always be
vulnerabilities and sandboxing can help to contain the consequences of
their exploitation.

However it is to be said, that sandboxing does not protect the contained
application and the data it has access to. Therefore sandboxing a
browser will not prevent the compromisation of the data you access with
it. Sandboxing a browser has therefore only limited use.




> In the end, every sandbox uses DAC protection, no? And I already proposed a
> sandbox which is far better than firejail or the one used in chrome, and
> doesn't use userns.
> 

Please take a look at bubblewrap
https://github.com/projectatomic/bubblewrap

On the default arch kernel it does not use user namespaces.

It is also use by tails to sandbox firefox or rather the tor browser


And chromium actually uses quite some nice sandboxing and has become
quite famous for being nearly unbreakable. They also have a bug bounty
programm, so if you find a way to break out of their sandbox you can get
up to 100k. Good luck :)


>>
>> Without any real prove of the claims you made in your post, it seems you
>> rather have a personal grudge against this feature while at the same
>> time saying you know better then all these people.
>> Sorry but that is pretty rich.
> 
> The issue is this: either enable userns fully, i.e. unprivileged users are
> able to create user namespaecs, or don't enable them at all. The way Fedora
> does things, for example, is worse that the latter (of course, if you used
> Fedora you know that it sucks in general).
> 

grsecurity has user namespaces enabled but restricted to privileged
users only. This allows privileged apps like docker to use this feature.
I think they know what they are doing.

btw. what does fedora do exactly? (I think I found somthing about a
kernel module parameter to enable userns. not sure why that is bad)

>> Don’t get me wrong I would love to discuss with you about this all day
>> long but I would like to ask you to reconsider your tone, as you sound
>> incredibly arrogant when you put yourself above all those voices/people
>> without providing real prove for your arguments.
> 
> So, why don't you just build your own kernel? It takes only 20 mins...
> 
> Cheers,
> 

thats not helping. And this is not about me getting this feature but
about a ton of applications that use suid and other shit to work around
this problem, which creates a lot of security problems for arch only.

And yes as pointed out without using these apps the kernel without
userns might be safer, but this still does not solve the general issue.




Am 01.02.2017 um 22:22 schrieb Martin Kühne via arch-general:
> As somebody with no actual knowledge of the details you guys are
> arguing over, but it seems to me OP has yet to learn that a simpler
> and more secure environment can only be achieved by using fewer and
> powerful components instead of many useless ones.

the features in question are inside the kernel and apart from user
namespaces there is no controvery that these features are helpful to
build containers.

But to provide unprivileged users with the ability to use namespaces,
user namespaces are required.


> Okay, there might be
> a point from which the amount of components will add enough obscurity
> to the overall system that simply nobody will bother trying to break
> it, but really, what's the big deal. I think sandboxing is a concept
> reminding too much of windows tools such as bullguard, which simply
> doesn't translate well enough (read: at all) to unixes, so I recommend
> checking whether you can trust the few things you use instead of
> adding a whole bunch of potempkin barriers. It's actually less work
> overall, too.

Not really sure what your point is here.
Sandboxing is not a concept from windows and that bullguard looks like
garbage after 0.1 seconds of looking at is, so no that does not compare.

Sandboxing has many aspects and is not bount to any plattform.

It should be said though, that sandboxing is not a replacement for
secure coding and has its limits.





signature.asc
Description: OpenPGP digital signature

Re: [arch-general] user namespaces

[sivmu]

Am 01.02.2017 um 21:21 schrieb Daniel Micay via arch-general:
>>> it's a nearly useless feature. 
>>
>> That's a baseless claim, that was already proved wrong in my first
>> post
>> by the many applications that use this feature.
> 
> That doesn't demonstrate that it's useful relative to the alternatives.
> It enables unprivileged OS containers but isn't really any use for app
> containers.
> 

Pretty much all famous container programms use this. I wonder why if
there is no use for it.

Also I would still like to see a simple alternative for unprivileged
namespaces to sandbox apps.
How do you provide something like bubblewrap without user namespaces?
And no that android example below is not the same as long as there is no
simple way to use this (which I am not aware of)


>>> but no one really wants it for that reason. They
>>> want it because it started pretending that it can offer something
>>> that
>>> it can't actually deliver safely.
>>
>> Again a claim without prove
> 
> The proof is easy to find. You're the one making a proposal but you
> clearly haven't done your research. It's not my job to spoon feed you.
> 

I do know some of the discussions about this feature on the kernel
mailing list. But the opinions even there are not as clear as you want
to make us believe.


>>> There are much better ways to do
>>> unprivileged sandboxes with significantly less risk than
>>> CLONE_NEWUSER
>>> or setuid executables where the user controls the environment.
>>
>> And yet you fail to name even one alternative. Please do
> 
> Uh, yeah, I did. M
> 

Sorry but 'M' ? I don't get it.

>>> Anything
>>> depending on this mechanism instead of properly designed plumbing
>>> for it
>>> is simply lazy garbage.
>>
>> Another baseless and arrogant claim
> 
> Not baseless and it's not arrogant to point out that this is a bad
> feature for app containers. It's the truth.

even if that is correct, it is a pretty weird/funny argument to say it's
the truth ... :)


>>> There's still an unrelenting torrent of security issues from it. 
>>
>> Name one
> 
> Look at the discussion on the issue report or do basic research on the
> topic. It's your proposal, if you haven't done even basic research
> that's your problem.

I did, but we differ about the interpretations (see below)


> 
>>> Maybe wait until that stops before proposing this. 
>>
>> Vulnerabilities in kernel features will never stop to exist. If we
>> disable everything with potential vulnerabilities, we did not have a
>> kernel anymore.
> 
> It's a very niche feature with better alternatives for sandboxes and app
> containers. It exposes all of the netfilter administration code and tons
> of other networking and mount code as new attack surface.

Point taken


>>
>> Android uses minijail (default app sandbox in android 7), which relies
>> on user namespaces…
>> Just opened a terminal on my android and checked it. Its inside a user
>> namespaces.
> 
> No, that's incorrect and you're just further demonstrating how far out
> of your depth you are here. Google doesn't even enable user namespaces
> in the kernel in AOSP / stock Android for Nexus/Pixel. Doubt that any
> other vendors are enabling it. It doesn't use any namespaces other than
> mount namespaces as part of the multi-user emulation for backwards
> compatibility. It certainly doesn't use minijail as the 'default app
> sandbox'. It uses minijail as a library to factor out common patterns
> involved in privilege dropping, like dropping capabilities. The app
> sandbox is done with uid/gid pairs (AIDs) and the full system SELinux
> policy (untrusted_app domain for regular non-platform apps and
> isolated_app for isolatedProcess services). Permissions are generally
> done with IPC checks but some are done with secondary groups. Before it
> had SELinux, it was just using the POSIX user/group/permission model to
> implement the app sandbox and that's still the base. It has no use case
> at all for user namespaces, and process namespaces would not really have
> much use either due to hidepid=2 since 7.x combined with uid isolation.
> It would just be a mess since they turn a process into a subreaper /
> secondary init.
> 
> Trying to explain to me how Android works from skimming and
> misinterpreting news / documentation and making incorrect assumptions is
> not going to get you far.
> 

Considering what you do for a living I believe you here.

However that also means that A LOT of documentation about how chromium,
android and minijail work is completely wrong. Which is kinda disturbing...


>>>
>>
>> Again no real life example for an alternative
> 
> Android, which was given as an example. You are going out of the way to
> ignore all of the information that's right in front of you.
> 

I am talking about alternatives that provide the same funktionality as
the full set of namespaces like bubblewrap does.



>>  I can point to 30+ kernel bugs from the
>>> past couple years that are privesc via user namespaces. Also those

Re: [arch-general] Generating gdb debug logs for devs

[Pekka Järvinen via arch-general]

Hi,

Here's the configs:

lxrandr:
% cat PKGBUILD
# $Id: PKGBUILD 162929 2016-02-21 01:19:49Z bgyorgy $
# Maintainer: Sergej Pupykin 
# Contributor: Geoffroy Carrier 

options=(debug !strip)
pkgbase=lxrandr
pkgname=(lxrandr lxrandr-gtk3)
pkgver=0.3.1
pkgrel=1
pkgdesc="Monitor configuration tool (part of LXDE)"
arch=('i686' 'x86_64')
license=('GPL2')
url="http://lxde.org/;
depends=('gtk2' 'gtk3' 'xorg-xrandr')
makedepends=('intltool')
source=("http://downloads.sourceforge.net/lxde/$pkgbase-$pkgver.tar.xz;)
md5sums=('b327938f18a4baac85c4707f927d606e')

build() {
  export CFLAGS="$CFLAGS -O0 -fbuiltin -g"
  export CXXFLAGS="$CXXFLAGS -O0 -fbuiltin -g"
  # GTK+ 2 version
  [ -d gtk2 ] || cp -r $pkgbase-$pkgver gtk2
  cd gtk2
  ./configure --sysconfdir=/etc --prefix=/usr
  make

  cd "$srcdir"
  # GTK+ 3 version
  [ -d gtk3 ] || cp -r $pkgbase-$pkgver gtk3
  cd gtk3
  ./configure --sysconfdir=/etc --prefix=/usr --enable-gtk3
  make
}

package_lxrandr() {
  groups=('lxde')
  depends=('gtk2' 'xorg-xrandr')

  cd gtk2
  make DESTDIR="$pkgdir" install
}

package_lxrandr-gtk3() {
  groups=('lxde-gtk3')
  pkgdesc+=' (GTK+ 3 version)'
  depends=('gtk3' 'xorg-xrandr')
  conflicts=('lxrandr')

  cd gtk3
  make DESTDIR="$pkgdir" install
}

-
% cat /etc/makepkg-debug.conf | grep -v ^#

DLAGENTS=('ftp::/usr/bin/curl -fC - --ftp-pasv --retry 3 --retry-delay 3 -o
%o %u'
  'http::/usr/bin/curl -fLC - --retry 3 --retry-delay 3 -o %o %u'
  'https::/usr/bin/curl -fLC - --retry 3 --retry-delay 3 -o %o %u'
  'rsync::/usr/bin/rsync --no-motd -z %u %o'
  'scp::/usr/bin/scp -C %u %o')


VCSCLIENTS=('bzr::bzr'
'git::git'
'hg::mercurial'
'svn::subversion')

CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"

CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"

BUILDENV=(!distcc color !ccache check !sign)

OPTIONS=(!strip docs !libtool !staticlibs emptydirs zipman purge !optipng
!upx debug)

INTEGRITY_CHECK=(md5)
STRIP_BINARIES="--strip-all"
STRIP_SHARED="--strip-unneeded"
STRIP_STATIC="--strip-debug"
MAN_DIRS=({usr{,/local}{,/share},opt/*}/{man,info})
DOC_DIRS=(usr/{,local/}{,share/}{doc,gtk-doc} opt/*/{doc,gtk-doc})
PURGE_TARGETS=(usr/{,share}/info/dir .packlist *.pod)


COMPRESSGZ=(gzip -c -f -n)
COMPRESSBZ2=(bzip2 -c -f)
COMPRESSXZ=(xz -c -z -)
COMPRESSLRZ=(lrzip -q)
COMPRESSLZO=(lzop -q)
COMPRESSZ=(compress -c -f)

PKGEXT='.pkg.tar.xz'
SRCEXT='.src.tar.gz'



2017-02-02 2:05 GMT+02:00 Martin Kühne via arch-general <
arch-general@archlinux.org>:

> So uh for all this to take effect you have to do the updates on the
> PKGBUILD options=(!strip debug) most notably I guess... not sure what
> makepkg.conf adjustments you made, but I'm pretty sure the main
> lifting is up to these two options being set.
>
> Is it possible that you would share the makepkg.conf you were using as
> well as the PKGBUILD you were doing the build with?
>
> cheers!
> mar77i
>



-- 
Pekka Järvinen

Re: [arch-general] Generating gdb debug logs for devs

[Martin Kühne via arch-general]

So uh for all this to take effect you have to do the updates on the
PKGBUILD options=(!strip debug) most notably I guess... not sure what
makepkg.conf adjustments you made, but I'm pretty sure the main
lifting is up to these two options being set.

Is it possible that you would share the makepkg.conf you were using as
well as the PKGBUILD you were doing the build with?

cheers!
mar77i

[arch-general] Generating gdb debug logs for devs

[Pekka Järvinen via arch-general]

Hi,

I have segfaulting lxrandr and I was referred to
https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces after filing
bug report.
I've installed ABS, modified PKGBUILD and made my own /etc/makepkg-dev.conf

makepkg -sf --config /etc/makepkg-dev.conf generates the executable.

Still gdb gives very little info after running
cd lxrandr/pkg/lxrandr/usr/bin
gdb -ex "set logging file debug.log" -ex "set logging overwrite on" -ex
"thread apply all bt full" -ex "set logging on" -ex "run" -ex "backtrace"
-ex "frame 0" -ex "kill" -ex "quit" ./lxrandr

I'm guessing because I need to add debugging to libraries which lxrandr is
using too.

In the wiki there's
--- snip ---
Note: It is insufficient to simply install the newly compiled debug
package, because the debugger will check that the file containing the debug
symbols is from the same build as the associated library and executable.
You must install both of the recompiled packages. In Arch, the debug
symbols files are installed under /usr/lib/debug. See the GDB documentation
for more information about debug packages.
--- snip ---

But as a non c/c++ dev this doesn't say anything. What do I need to
install/run and where?

So could the wiki page be enhanced by adding concrete example(s)?

Original bug report: https://bugs.archlinux.org/task/51480

-- 
Pekka Järvinen

Re: [arch-general] ofono install

[ProgAndy]

Am 01.02.2017 um 23:06 schrieb Peter Nabbefeld:


Hello,

I tried to install ofono from AUR, because I want HSP/HFP support for 
pulseaudio 
(https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index35h3), 
but I get an error about a conflict between .SRCINFO and PKGBUILD - 
how can I resolve this problem?


Kind regards
Peter


That sounds like you are using an AUR helper that compares the contents 
of the PKGBUILD to the .SRCINFO file that provides the display data for 
the AUR entry. The ofono maintainer only updated the PKGBUILD to 1.19 
forgot to regenerate the SRCINFO (it still shows 1.18).


In this case you should build the package manually using makepkg and at 
most a simple download helper like cower.



--

Andreas

Re: [arch-general] ofono install

[Maxwell Anselm via arch-general]

>
> I get an error about a conflict between .SRCINFO and PKGBUILD - how can I
> resolve this problem?
>

I'm not getting that error, have you tried cloning a fresh copy from AUR?
Regardless, you don't need to care about .SRCINFO unless you're the
maintainer. Just delete it.

Max

[arch-general] ofono install

[Peter Nabbefeld]

Hello,

I tried to install ofono from AUR, because I want HSP/HFP support for 
pulseaudio 
(https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index35h3), 
but I get an error about a conflict between .SRCINFO and PKGBUILD - how 
can I resolve this problem?


Kind regards
Peter

Re: [arch-general] user namespaces

[Martin Kühne via arch-general]

As somebody with no actual knowledge of the details you guys are
arguing over, but it seems to me OP has yet to learn that a simpler
and more secure environment can only be achieved by using fewer and
powerful components instead of many useless ones. Okay, there might be
a point from which the amount of components will add enough obscurity
to the overall system that simply nobody will bother trying to break
it, but really, what's the big deal. I think sandboxing is a concept
reminding too much of windows tools such as bullguard, which simply
doesn't translate well enough (read: at all) to unixes, so I recommend
checking whether you can trust the few things you use instead of
adding a whole bunch of potempkin barriers. It's actually less work
overall, too.

cheers!
mar77i

Re: [arch-general] user namespaces

[Daniel Micay via arch-general]

On Wed, 2017-02-01 at 19:51 +0100, sivmu wrote:
> 
> Am 01.02.2017 um 07:20 schrieb Daniel Micay via arch-general:
> > On Wed, 2017-02-01 at 00:18 +0100, sivmu wrote:
> > > Summary:
> > > 
> > > Arch Linux is one of the few, if not the only distribution that
> > > still
> > > disables or restricts the use of unprivileged user namespaces, a
> > > feature
> > > that is used by many applications and containers to provide secure
> > > sandboxing.
> > > There have been request to turn this feature on since Linux 3.13
> > > (in
> > > 2013) but they are still being denied. While there may have been
> > > some
> > > reason for doing so a few year ago, leading to many distributions
> > > like
> > > Debian and Red Hat to restrict its use to privileged users via a
> > > kernel
> > > patch (they never disabled it completely), today arch seems to be
> > > the
> > > only distribution to block this feature. Even conservative distros
> > > like
> > > Debian 8 and 9 have this feature fully enabled.
> > 
> > There are still endless unprivileged user namespace vulnerabilities
> 
> 
> You failed to name even one.

I already listed several in the linked issue reports.

> > it's a nearly useless feature. 
> 
> That's a baseless claim, that was already proved wrong in my first
> post
> by the many applications that use this feature.

That doesn't demonstrate that it's useful relative to the alternatives.
It enables unprivileged OS containers but isn't really any use for app
containers.

> > The uid/gid mapping is poorly thought out
> > and immature without the necessary environment (filesystem support,
> > etc.) built around it, 
> 
> Something like mount namespaces, that are designed to be used in
> combination with user namespaces?

That has nothing to do with this.

> > but no one really wants it for that reason. They
> > want it because it started pretending that it can offer something
> > that
> > it can't actually deliver safely.
> 
> Again a claim without prove

The proof is easy to find. You're the one making a proposal but you
clearly haven't done your research. It's not my job to spoon feed you.

> > There are much better ways to do
> > unprivileged sandboxes with significantly less risk than
> > CLONE_NEWUSER
> > or setuid executables where the user controls the environment.
> 
> And yet you fail to name even one alternative. Please do

Uh, yeah, I did. M

> > Anything
> > depending on this mechanism instead of properly designed plumbing
> > for it
> > is simply lazy garbage.
> 
> Another baseless and arrogant claim

Not baseless and it's not arrogant to point out that this is a bad
feature for app containers. It's the truth.

> > Lack of a proper layer on top of the kernel
> > providing infrastructure (systemd is so far from that) on
> > desktop/server
> > Linux is not going to be fixed by delegating everything to the
> > kernel
> > even when it massively increases attack surface.
> > 
> > > I would like to suggest that arch stops to disable this feature in
> > > future kernel versions.
> > > 
> > > Resoning:
> > > 
> > > The original reason to block user namespaces were a number of
> > > security
> > > issues that allowed unprivileged users to access features they
> > > should
> > > not have access to. Due to the nature of user namespaces to
> > > provide
> > > isolated user environments with access to privileged features like
> > > other
> > > namespaces (inside that isolated namespace only), it should be
> > > obvious
> > > that this feature had to be designed carefully in order not to
> > > harm
> > > the
> > > security outside the namespace. Even though there have been
> > > issues,
> > > this
> > > feature is now considered stable enough for distros like debian
> > > and
> > > red
> > > hat to allow its use even for unprivileged users.
> > 
> > There's still an unrelenting torrent of security issues from it. 
> 
> Name one

Look at the discussion on the issue report or do basic research on the
topic. It's your proposal, if you haven't done even basic research
that's your problem.


> > Maybe wait until that stops before proposing this. 
> 
> Vulnerabilities in kernel features will never stop to exist. If we
> disable everything with potential vulnerabilities, we did not have a
> kernel anymore.

It's a very niche feature with better alternatives for sandboxes and app
containers. It exposes all of the netfilter administration code and tons
of other networking and mount code as new attack surface.

> > I don't think it's going to
> > stop because of how this feature is designed. It greatly increases
> > the
> > attack surface and there isn't going to be a mitigating factor that
> > changes this situation. It's a fundamentally flawed, garbage feature
> > and
> >  the arguments for it are nonsense. There are better ways to do
> > this, by
> > simply not tying your hands and refusing to implement anything in
> > user
> > space but instead pretending that all common features must happen in
> > the
> > kernel despite 

Re: [arch-general] user namespaces

[Leonid Isaev]

On Wed, Feb 01, 2017 at 07:51:49PM +0100, sivmu wrote:
> The people responsible for linux distributions like debian, red hat and
> pretty much all other distros, as well as many developers of sandboxing
> applications including the tails and chromium people all believe this
> feature is a useful tool to provide unprivileged sandbox applications
> worth the risk.

But you see, sandboxing apps is by itself is a misleading security feature. Why
do I need to sandbox my browser if it is written properly and allows me to
disable the unnecessary (for me) features?

In the end, every sandbox uses DAC protection, no? And I already proposed a
sandbox which is far better than firejail or the one used in chrome, and
doesn't use userns.

> 
> Without any real prove of the claims you made in your post, it seems you
> rather have a personal grudge against this feature while at the same
> time saying you know better then all these people.
> Sorry but that is pretty rich.

The issue is this: either enable userns fully, i.e. unprivileged users are
able to create user namespaecs, or don't enable them at all. The way Fedora
does things, for example, is worse that the latter (of course, if you used
Fedora you know that it sucks in general).

> Don’t get me wrong I would love to discuss with you about this all day
> long but I would like to ask you to reconsider your tone, as you sound
> incredibly arrogant when you put yourself above all those voices/people
> without providing real prove for your arguments.

So, why don't you just build your own kernel? It takes only 20 mins...

Cheers,
-- 
Leonid Isaev

Re: [arch-general] user namespaces

[sivmu]

Am 01.02.2017 um 07:20 schrieb Daniel Micay via arch-general:
> On Wed, 2017-02-01 at 00:18 +0100, sivmu wrote:
>> Summary:
>>
>> Arch Linux is one of the few, if not the only distribution that still
>> disables or restricts the use of unprivileged user namespaces, a
>> feature
>> that is used by many applications and containers to provide secure
>> sandboxing.
>> There have been request to turn this feature on since Linux 3.13 (in
>> 2013) but they are still being denied. While there may have been some
>> reason for doing so a few year ago, leading to many distributions like
>> Debian and Red Hat to restrict its use to privileged users via a
>> kernel
>> patch (they never disabled it completely), today arch seems to be the
>> only distribution to block this feature. Even conservative distros
>> like
>> Debian 8 and 9 have this feature fully enabled.
> 
> There are still endless unprivileged user namespace vulnerabilities


You failed to name even one.


> it's a nearly useless feature. 

That's a baseless claim, that was already proved wrong in my first post
by the many applications that use this feature.


> The uid/gid mapping is poorly thought out
> and immature without the necessary environment (filesystem support,
> etc.) built around it, 

Something like mount namespaces, that are designed to be used in
combination with user namespaces?

> but no one really wants it for that reason. They
> want it because it started pretending that it can offer something that
> it can't actually deliver safely.

Again a claim without prove

> There are much better ways to do
> unprivileged sandboxes with significantly less risk than CLONE_NEWUSER
> or setuid executables where the user controls the environment.

And yet you fail to name even one alternative. Please do

> Anything
> depending on this mechanism instead of properly designed plumbing for it
> is simply lazy garbage.

Another baseless and arrogant claim

> Lack of a proper layer on top of the kernel
> providing infrastructure (systemd is so far from that) on desktop/server
> Linux is not going to be fixed by delegating everything to the kernel
> even when it massively increases attack surface.
> 
>> I would like to suggest that arch stops to disable this feature in
>> future kernel versions.
>>
>> Resoning:
>>
>> The original reason to block user namespaces were a number of security
>> issues that allowed unprivileged users to access features they should
>> not have access to. Due to the nature of user namespaces to provide
>> isolated user environments with access to privileged features like
>> other
>> namespaces (inside that isolated namespace only), it should be obvious
>> that this feature had to be designed carefully in order not to harm
>> the
>> security outside the namespace. Even though there have been issues,
>> this
>> feature is now considered stable enough for distros like debian and
>> red
>> hat to allow its use even for unprivileged users.
> 
> There's still an unrelenting torrent of security issues from it. 

Name one

> Maybe wait until that stops before proposing this. 

Vulnerabilities in kernel features will never stop to exist. If we
disable everything with potential vulnerabilities, we did not have a
kernel anymore.

> I don't think it's going to
> stop because of how this feature is designed. It greatly increases the
> attack surface and there isn't going to be a mitigating factor that
> changes this situation. It's a fundamentally flawed, garbage feature and
>  the arguments for it are nonsense. There are better ways to do this, by
> simply not tying your hands and refusing to implement anything in user
> space but instead pretending that all common features must happen in the
> kernel despite major security risks and poor semantics.
> 

So this is actually about you not liking this feature without naming any
real reason making a bunch of baseless accusations and claims.


>> Moreover there are many applications that use this feature to provide
>> or
>> enhance security
>> Among them are:
>>
>> lxc, systemd-nspawn, docker, flatpak, bubblewrap, firejail, firefox,
>> chromium
> 
> There's one well-written sandbox there (Chromium's usage) and it doesn't
> require this feature. 

Wrong

https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md

And for suid:

Quote:
„The intention is if you want to run Chrome and only use the namespace
sandbox, you can set --disable-setuid-sandbox.  But if you do so on a
host without appropriate kernel support for the namespace sandbox,
Chrome will loudly refuse to run.“

Source:
https://bugs.chromium.org/p/chromium/issues/detail?id=598454


They also don't need this feature on platforms
> where they have control like Android, since they can implement it in a
> saner way where it doesn't massively increase kernel attack surface.
> 

Android uses minijail (default app sandbox in android 7), which relies
on user namespaces…
Just opened a terminal on my android and checked it. 

Re: [arch-general] systemd latest upgrade

[Jude DaShiell]

Thanks for this information, the last update I did this morning didn't 
have the Arming message show up so I think maybe an update closed this 
vulnerability.


On Wed, 1 Feb 2017, Jelle van der Waa wrote:


Date: Wed, 1 Feb 2017 04:12:52
From: Jelle van der Waa 
Reply-To: General Discussion about Arch Linux 
To: General Discussion about Arch Linux 
Subject: Re: [arch-general] systemd latest upgrade

On 01/31/17 at 04:18pm, Jude DaShiell wrote:

For the last several systemd upgrades an error complaining about a missing
uefi directory has come out when those upgrades were being installed. Today
that happened too.


No clue


However any package install now finishes with the
message:
Arming ConditionNeedsUpdate 


That's just a pacman hook to touch /var, for the recent CVE issue in
systemd  [1] [2]

[1] 
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/systemd=59541b72a7ec32b30343a2a388b40ea1365f6308
[2] http://www.openwall.com/lists/oss-security/2017/01/24/4




--

Re: [arch-general] HSP/HFP profile on Bluetooth Headset causing problems

[Joan Aymà via arch-general]

How you change between a2dp and hsp/hfp profiles? What's the output
of pacmd list-sinks before and after?
Does it works well without jack?




Joan.

2017-01-31 8:00 GMT+01:00 Peter Nabbefeld :

> Am 30.01.2017 um 21:49 schrieb Jerome Leclanche:
>
>> On Mon, Jan 30, 2017 at 5:26 PM, Peter Nabbefeld 
>> wrote:
>>
>>>
>>> Hello,
>>>
>>> I want to use HSP/HFP profile on a Bluetooth Headset, because its
>>> microphone
>>> doesn't work with A2DP.
>>>
>>> When I activate the headset with HSP/HFP profile, it works until I stop
>>> speaking. Headset input is turned off then, and isn't turned on even when
>>> speaking again.
>>>
>>> Using jack2-dbus and pulseaudio, latest update this morning.
>>>
>>> Kind regards
>>> Peter
>>>
>>
>> What's the headset model?
>> J. Leclanche
>>
>>
> Found package hfpforlinux-svn in AUR, but that's not compileable.
>

Re: [arch-general] systemd latest upgrade

[LoneVVolf]

On 01-02-17 10:12, Jelle van der Waa wrote:

On 01/31/17 at 04:18pm, Jude DaShiell wrote:

However any package install now finishes with the
message:
Arming ConditionNeedsUpdate 


That's just a pacman hook to touch /var, for the recent CVE issue in
systemd  [1] [2]

[1] 
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/systemd=59541b72a7ec32b30343a2a388b40ea1365f6308
[2] http://www.openwall.com/lists/oss-security/2017/01/24/4



The new hook checks for changes in and touches /usr, not /var or /run .

A search for systemd ConditionNeedsUpdate gives [*] .

that condition appears to be used for determining whether a change in 
/usr requires changes in /etc or /var.


There are some archlinux systemd services that use 
ConditionNeedsUpdate=/etc , but i can find none that use it with /var .


looks to me like this hook either fails defending fromn that CVE or has 
some other purpose.


LW





[*] 
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#ConditionNeedsUpdate=

Re: [arch-general] systemd latest upgrade

[Jelle van der Waa]

On 01/31/17 at 04:18pm, Jude DaShiell wrote:
> For the last several systemd upgrades an error complaining about a missing
> uefi directory has come out when those upgrades were being installed. Today
> that happened too.

No clue

> However any package install now finishes with the
> message:
> Arming ConditionNeedsUpdate 

That's just a pacman hook to touch /var, for the recent CVE issue in
systemd  [1] [2]

[1] 
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/systemd=59541b72a7ec32b30343a2a388b40ea1365f6308
[2] http://www.openwall.com/lists/oss-security/2017/01/24/4

-- 
Jelle van der Waa


signature.asc
Description: PGP signature

Re: [arch-general] user namespaces

[Leonid Isaev]

On Wed, Feb 01, 2017 at 02:45:46AM -0500, Daniel Micay wrote:
> Application containers don't have a use for the user namespace quasi
> root and no one really needs the half baked uid/gid mapping feature.
> There's no real reason for stuff being done that way beyond desktop
> Linux having the disease of inability to do plumbing in userspace, but
> instead putting everything in the kernel simply to have it universally
> available rather than for technical reasons.
> 
> It would make sense to simply have a service spawning on-demand unpriv
> users from a range of uid/gid pairs. That's exactly how this works on
> Android for both apps and isolatedProcess services (they each get a
> unique uid/gid pair assigned), although they also layer SELinux and
> mount namespaces on top.

Cool :) thx for the explanation...

Cheers,
L.

-- 
Leonid Isaev