Re: [lxc-users] is starting unprivileged containers as root as secure as running them as any other user?

2016-01-13 Thread Carlos Alberto Lopez Perez 
On 11/01/16 23:36, Serge Hallyn wrote:
> The lxc-attach weakness I mentioned does not apply to 'lxc exec', because
> lxd interposes a pty between your console and the container's.

I understand that I could do the same (get a fresh PTY before attaching) with
(for example): "screen lxc-attach ..." [1]

Do you think it will be a good idea to patch lxc-attach to automatically do
that (get a fresh PTY before attaching) ?

Will this solve all know security issues regarding the usage of lxc-attach ?
Or there is something more than I'm missing other than the PTY vulnerability?


Regards.

[1] https://service.ait.ac.at/security/2015/LxcSecurityAnalysis.html



signature.asc
Description: OpenPGP digital signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] is starting unprivileged containers as root as secure as running them as any other user?

2016-01-13 Thread Saint Michael 
I noticed that lxc-attach does not run
source /etc/profile
and that is an issue since we set many environment variables and settings
that are needed for what comes next.
Is there a workaround?

On Wed, Jan 13, 2016 at 4:49 PM, Serge Hallyn 
wrote:

> Quoting Carlos Alberto Lopez Perez (clo...@igalia.com):
> > On 11/01/16 23:36, Serge Hallyn wrote:
> > > The lxc-attach weakness I mentioned does not apply to 'lxc exec',
> because
> > > lxd interposes a pty between your console and the container's.
> >
> > I understand that I could do the same (get a fresh PTY before attaching)
> with
> > (for example): "screen lxc-attach ..." [1]
> >
> > Do you think it will be a good idea to patch lxc-attach to automatically
> do
> > that (get a fresh PTY before attaching) ?
>
> Yes, I'd really like someone to do that.  It's on my list,
> but that list is pretty long.
>
> > Will this solve all know security issues regarding the usage of
> lxc-attach ?
>
> I think so.
>
> > Or there is something more than I'm missing other than the PTY
> vulnerability?
> >
> >
> > Regards.
> >
> > [1] https://service.ait.ac.at/security/2015/LxcSecurityAnalysis.html
> >
>
>
>
> > ___
> > lxc-users mailing list
> > lxc-users@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
>
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] CGManager error on debian

2016-01-13 Thread Joshua Schaeffer 
I'm getting an error when trying to start an unprivileged container on
Debian Jessie. LXC version 1.1.2. I installed CGManager using the
instructions here: https://linuxcontainers.org/cgmanager/getting-started/.
There weren't any problems installing. Creating the container succeeded
without issue.

jschaeffer@prvlxc01:~$ lxc-start -n append01
Connection from private client
Disconnected from private client
Connection from private client
Disconnected from private client
Connection from private client
Disconnected from private client
Connection from private client
Disconnected from private client
Connection from private client
Disconnected from private client
Connection from private client
Connection from private client
Create: Client fd is: 7 (pid=3994, uid=1000, gid=1000)
cgmanager:do_create_main: pid 3994 (uid 1000 gid 1000) may not create under
/run/cgmanager/fs/blkio
cgmanager:do_create_main: pid 3994 (uid 1000 gid 1000) may not create under
/run/cgmanager/fs/cpu
cgmanager:do_create_main: pid 3994 (uid 1000 gid 1000) may not create under
/run/cgmanager/fs/cpuset
cgmanager:do_create_main: pid 3994 (uid 1000 gid 1000) may not create under
/run/cgmanager/fs/devices
cgmanager:do_create_main: pid 3994 (uid 1000 gid 1000) may not create under
/run/cgmanager/fs/freezer
cgmanager:do_create_main: pid 3994 (uid 1000 gid 1000) may not create under
/run/cgmanager/fs/memory
cgmanager:do_create_main: pid 3994 (uid 1000 gid 1000) may not create under
/run/cgmanager/fs/net_cls
cgmanager:do_create_main: pid 3994 (uid 1000 gid 1000) may not create under
/run/cgmanager/fs/perf_event
cgmanager:do_create_main: pid 3994 (uid 1000 gid 1000) may not create under
/run/cgmanager/fs/none,name=systemd/system.slice/ssh.service
cgmanager_create: returning 0; existed is -1
Disconnected from private client
Connection from private client
MovePid: Client fd is: 7 (pid=3994, uid=1000, gid=1000)
cgmanager: Invalid path /run/cgmanager/fs/perf_event/lxc/append01
cgmanager:per_ctrl_move_pid_main: Invalid path
/run/cgmanager/fs/perf_event/lxc/append01
Disconnected from private client
Connection from private client
Disconnected from private client
Remove: Client fd is: 7 (pid=3994, uid=1000, gid=1000)
Disconnected from private client
lxc-start: lxc_start.c: main: 344 The container failed to start.
lxc-start: lxc_start.c: main: 346 To get more details, run the container in
foreground mode.
lxc-start: lxc_start.c: main: 348 Additional information can be obtained by
setting the --logfile and --logpriority options.


jschaeffer@prvlxc01:~$ cat ~/.local/share/lxc/
append01/ c1/   c3/   lxc-monitord.log
jschaeffer@prvlxc01:~$ cat ~/.local/share/lxc/append01/append01.log
  *lxc-start 1452726692.572 ERRORlxc_cgmanager -
cgmanager.c:lxc_cgmanager_enter:694 - call to cgmanager_move_pid_sync
failed: invalid request*
  lxc-start 1452726692.657 ERRORlxc_start -
start.c:__lxc_start:1164 - failed to spawn 'append01'
  lxc-start 1452726697.662 ERRORlxc_start_ui - lxc_start.c:main:344
- The container failed to start.
  lxc-start 1452726697.662 ERRORlxc_start_ui - lxc_start.c:main:346
- To get more details, run the container in foreground mode.
  lxc-start 1452726697.663 ERRORlxc_start_ui - lxc_start.c:main:348
- Additional information can be obtained by setting the --logfile and
--logpriority options.


I've done a little searching on "call to cgmanager_move_pid_sync failed"
but couldn't find anything that useful.
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] is starting unprivileged containers as root as secure as running them as any other user?

2016-01-13 Thread Serge Hallyn 
Quoting Carlos Alberto Lopez Perez (clo...@igalia.com):
> On 11/01/16 23:36, Serge Hallyn wrote:
> > The lxc-attach weakness I mentioned does not apply to 'lxc exec', because
> > lxd interposes a pty between your console and the container's.
> 
> I understand that I could do the same (get a fresh PTY before attaching) with
> (for example): "screen lxc-attach ..." [1]
> 
> Do you think it will be a good idea to patch lxc-attach to automatically do
> that (get a fresh PTY before attaching) ?

Yes, I'd really like someone to do that.  It's on my list,
but that list is pretty long.

> Will this solve all know security issues regarding the usage of lxc-attach ?

I think so.

> Or there is something more than I'm missing other than the PTY vulnerability?
> 
> 
> Regards.
> 
> [1] https://service.ait.ac.at/security/2015/LxcSecurityAnalysis.html
> 



> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] CGManager error on debian

2016-01-13 Thread Fajar A. Nugraha 
On Thu, Jan 14, 2016 at 6:13 AM, Joshua Schaeffer 
wrote:

> I'm getting an error when trying to start an unprivileged container on
> Debian Jessie. LXC version 1.1.2.
>

Why 1.1.2? Where did you get it from?

Latest version is 1.1.5, while jessie's version is 1.0.8


> I installed CGManager using the instructions here:
> https://linuxcontainers.org/cgmanager/getting-started/. There weren't any
> problems installing. Creating the container succeeded without issue.
>
> jschaeffer@prvlxc01:~$ lxc-start -n append01
>

Create: Client fd is: 7 (pid=3994, uid=1000, gid=1000)
> cgmanager:do_create_main: pid 3994 (uid 1000 gid 1000) may not create
> under /run/cgmanager/fs/blkio
>


My guess is your user session does not have its own cgroups. See
http://debian-lxc.github.io/Create%20Unprivileged%20Jessie%20Container.html

In particular, the smallest modification you need to make is
http://debian-lxc.github.io/Create%20User-Owned%20Cgroup.html

If you're willing to use third-party packages, you can simply follow the
entire howto: http://debian-lxc.github.io/installation.html

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] is starting unprivileged containers as root as secure as running them as any other user?

2016-01-13 Thread Andrey Repin 
Greetings, Saint Michael!

> I noticed that lxc-attach does not run

> source /etc/profile

> and that is an issue since we set many environment variables and settings 
> that are needed for what comes next.

> Is there a workaround?

lxc-attach -n container -- sudo -i


-- 
With best regards,
Andrey Repin
Thursday, January 14, 2016 06:55:42

Sorry for my terrible english...

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] In LXD/LXC container avahi-daemon fails installation

2016-01-13 Thread brian mullan 
I have been trying to figure out why in my LXC container the avahi-daemon
fails.

Because the avahi-daemon fails other apps that have it as a dependency fail
to install also!

This morning I happened to find this post:
https://gist.github.com/jpouellet/c0d0698d669f1f364ab3

The author was encountering the same problem & errors as I have been seeing:

*update-rc.d: warning: start and stop actions are no longer supported;
falling back to defaults
Job for avahi-daemon.service failed because the control process exited
with error code. See "systemctl status avahi-daemon.service" and
"journalctl -xe" for details.
invoke-rc.d: initscript avahi-daemon, action "start" failed.
dpkg: error processing package avahi-daemon (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of libnss-mdns:amd64:
 libnss-mdns:amd64 depends on avahi-daemon (>= 0.6.16-1); however:
  Package avahi-daemon is not configured yet.

dpkg: error processing package libnss-mdns:amd64 (--configure):
 dependency problems - leaving unconfigured*


However... the author also had a work around to get avahi to install
successfully in LXC:

*$ sudo -s
# apt-get install avahi-daemon avahi-utils
... bunch of errors ...
# systemctl disable avahi-daemon
# systemctl stop avahi-daemon
# apt-get autoremove
# apt-get install -f avahi-daemon avahi-utils*


I tried his workaround and it did work for me also !

Once avahi installed OK the other programs that had a dependency on avahi
and avahi-daemon could also install correctly such as some of the
pulseaudio related software.

My Host is ubuntu 15.10, my LXC container is Ubuntu 15.10.

As this doesn't happen on my Host ... is this an LXC bug?

$ lxc --version
0.26

thanks
brian
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] config scripts for an LXC Ubuntu-Mate desktop

2016-01-13 Thread brian mullan 
I just put some scripts/files on github which will create an LXC container
your Host and install Ubuntu-Mate desktop in the container.

I've also utilized PulseAudio's TCP module to redirect any sound/audio from
the cn1 container
to your Host's speakers.

I'm hoping the README file and all the comments I put into the 2 scripts
explain everything.

On the Host there are minimal pre-reqs:

1)  pulseaudio must already be installed
2)  LXD must already be installed
3)  as the access to the LXC Mate desktop is via RDP (xrdp) Its recommended
you install
 xfreerdp to access the desktop instead of rdesktop as its faster &
more reliable & the
 command line is simpler to understand
4) you may need unzip installed to decompress the .zip file you download
from github.

During installation the scripts only make 1 change in the Host and that is
appending 2 lines to the */etc/pulse/system.pa * file so
Pulseaudio will load its TCP module on its next restart.

All of that is mentioned in either the README or comments in the scripts or
both.

Installation can take from 20-40 minutes depending on your Host (re ssd vs
hd, cpu type etc).

Once complete & the cn1 container rebooted you can use it.

If you wanted more containers setup like this you can just use LXC
clone/copy the original cn1 container.

I've only tested this on Ubuntu 15.04 and 15.10 so far.

The files can be found at:   https://github.com/bmullan/ciab-lxc-desktop

clipboard, sound & printing (may need to install CUPs and/or ghostscript in
cn1) all work.

Make sure to read anything I marked as "NOTE:".

I did uncover a couple bugs while doing this but I explain them again in
the README and/or in the comments in the scripts.

One was related to Firefox (how it starts from CLI vs Menu) and the other
was with installing the avahi-daemon in a container.

I filed a bug on the Firefox issue but also implemented a work-around for
it in the installation script.

The avahi installation problem I found someone else had hit and they had
posted their work-around on the web... it worked ... so I documented that
also.

Brian
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users