Re: [systemd-devel] SELinux type transition rule not working

[Ian Pilcher]

On 03/03/2017 02:19 PM, Simon Sekidde wrote:

Thanks. Lets try to get a template going and we can help clean it up.


I've been scrambling to get my home network setup (after migrating the
main network server/router from CentOS 6 -> 7), so it's not surprise if
things are a bit hacky right now.


 sepolicy generate --init -n squoxy /usr/local/bin/squoxy


Yet another tool that I've never heard of before.  So much outdated
info on SELinux out there.  :-(

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Can a systemd --user instance rely on After= of systemd --system instance?

[Kai Krakow]

Am Sun, 26 Feb 2017 21:35:27 +0100
schrieb Lennart Poettering :

> On Sat, 25.02.17 17:34, Patrick Schleizer
> (patrick-mailingli...@whonix.org) wrote:
> 
> > Hi,
> > 
> > I read, that a systemd --user instance cannot use Requires=.
> > 
> > But what about After=? Can a systemd --user instance use
> > After=some-system.service?  
> 
> The units of the --user instance live in an entirely disjunct
> namespace from those in the --system instance. Hence yes, you can
> absolutely use After= and/or Requires= between two user services, but
> it will always just be between two *user* services, and never between
> a user and a system service, since the unit state engines of the
> system and user instance are completely disconnected, as said.

Which brings me back to something I wondered about:

If I have a user service which needs to have the system database server
available: How do I construct a proper depend?

Currently, my user services time out during boot because the database
server is simply not ready fast enough. Thus I'd like to trigger
starting those services only after the database server is ready.

Even putting "Requires" and "After" into the user@ template doesn't
seem to respect this... (or I'm missing some secondary dependency)

My next attempt would be to fire up user sessions with a timer only
after a certain time has passed after boot. But that doesn't feel
right...

-- 
Regards,
Kai

Replies to list-only preferred.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SELinux type transition rule not working

[Simon Sekidde]

- Original Message -
> From: "Ian Pilcher" 
> To: "Simon Sekidde" 
> Cc: "Systemd" , seli...@tycho.nsa.gov
> Sent: Friday, March 3, 2017 2:32:54 PM
> Subject: Re: [systemd-devel] SELinux type transition rule not working
> 
> On 03/03/2017 10:45 AM, Simon Sekidde wrote:
> > Ian do you have a copy of this custom policy somewhere?
> 
> https://github.com/ipilcher/squoxy/blob/master/squoxy.te
> 

Thanks. Lets try to get a template going and we can help clean it up. 

 sepolicy generate --init -n squoxy /usr/local/bin/squoxy

> --
> 
> Ian Pilcher arequip...@gmail.com
>  "I grew up before Mark Zuckerberg invented friendship" 
> 
> 

-- 
Simon Sekidde * Red Hat, Inc. * Tyson's Corner, VA
Solution Architect, NA Public Sector
sseki...@redhat.com | (w) 978-392-1074 | (m) 571-551-9366 | @ssekidde
gpg: 5848 958E 73BA 04D3 7C06 F096 1BA1 2DBF 94BC 377E


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SELinux type transition rule not working

[Ian Pilcher]

On 03/03/2017 10:45 AM, Simon Sekidde wrote:

Ian do you have a copy of this custom policy somewhere?


https://github.com/ipilcher/squoxy/blob/master/squoxy.te

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SELinux type transition rule not working

[Simon Sekidde]

Ian do you have a copy of this custom policy somewhere?

- Original Message -
> From: "Simon Sekidde" 
> To: "Ian Pilcher" 
> Cc: "Systemd" , lenn...@poettering.net, 
> seli...@tycho.nsa.gov
> Sent: Friday, March 3, 2017 11:01:59 AM
> Subject: Re: [systemd-devel] SELinux type transition rule not working
> 
> 
> 
> - Original Message -
> > From: "Ian Pilcher" 
> > To: "Simon Sekidde" 
> > Cc: "Systemd" , seli...@tycho.nsa.gov,
> > lenn...@poettering.net
> > Sent: Friday, March 3, 2017 10:44:18 AM
> > Subject: Re: [systemd-devel] SELinux type transition rule not working
> > 
> > On 03/02/2017 09:13 AM, Simon Sekidde wrote:
> > > I assume this would be a pid file?
> > 
> > You assume correctly.
> > 
> > > If so then what you are probably looking for is a filename_trans rule
> > > and will require a new interface in squid.if for this.
> > >
> > > Try something like
> > >
> > > interface(`squid_filetrans_named_content',` gen_require(`
> > > type_squid_var_run_t; ')
> > >
> > > files_pid_filetrans($1, squid_var_run_t, dir, "squozy") ')
> > 
> > Not sure where squid came from.  The service is one of my own making
> > called "squoxy" (short for "Squeezebox proxy").  Its purpose is to
> > forward Squeezebox discovery broadcast packets from one network to
> > another.
> > 
> 
> Sorry I must have been doing something in the squid policy while I was
> responding to this...
> 
> > So I assume that I would need to add something like this to my policy
> > module:
> > 
> >files_pid_filetrans(var_run_t, squoxy_var_run_t, dir, "squoxy")
> > 
> > (I'm guessing at what to put in for $1.)
> > 
> 
> files_pid_filetrans(squoxy_t, squoxy_var_run_t, dir, "squoxy")
> 
> Files created by the squoxy_t processes in the var_run_t directory will be
> created with the squoxy_var_run_t label
> 
> > >> Hmm, so the relevant code in systemd actually labels the dir after
> > >> creating it after an selinux database lookup, so from our side all
> > >> should be good:
> > >>
> > >> https://github.com/systemd/systemd/blob/master/src/core/execute.c#L1857
> > >>
> > >>
> > >>(specifically, we all mkdir_p_label() instead of plain mkdir_p()
> >  >> there)
> > 
> > And this is working now, presumably after a reboot?  I do so love
> > non-deterministic computers.  :-/
> > 
> > --
> > 
> > Ian Pilcher arequip...@gmail.com
> >  "I grew up before Mark Zuckerberg invented friendship" 
> > 
> > 
> 
> 
> 
> ___
> Selinux mailing list
> seli...@tycho.nsa.gov
> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to
> selinux-requ...@tycho.nsa.gov.
> 




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SELinux type transition rule not working

[Stephen Smalley]

On Fri, 2017-03-03 at 09:36 -0600, Ian Pilcher wrote:
> On 03/02/2017 12:12 AM, Jason Zaman wrote:
> > 
> > On Wed, Mar 01, 2017 at 05:51:01PM -0600, Ian Pilcher wrote:
> > > 
> > > On 03/01/2017 05:28 PM, Ian Pilcher wrote:
> > > > 
> > > > Per Lennart's response, systemd *should* be honoring the file
> > > > context
> > > > rules when creating the directory.  It's almost as if the
> > > > directory is
> > > > being created with the proper context, but something is
> > > > changing it
> > > > after the fact.  I have absolutely no idea what that might be,
> > > > though.
> > 
> > Try using auditd to get details on everything going on in there:
> > auditctl -w /var/run/squoxy -p rwa -k watchsquoxy
> > 
> > then start things up and get everything matching with:
> > ausearch -k watchsquoxy
> 
> And wouldn't you know ... I can't reproduce the behavior
> now.  Sheesh!
> Must be one of these fancy new quantum computers.  (Something about
> rebooting 3 times comes to mind.)
> 
> > 
> > also, not sure if it was just weirdness in your email formatting,
> > but
> > you dont need the ^ at the front of an fcontext:
> > ^/var/run/squoxy
> 
> Does SELinux add an implicit ^ at the beginning of each expression?
> Otherwise, wouldn't /run/squoxy(/.*)? also match
> /foo/run/squoxy?  (Not
> necessarily likely, but ...)

SELinux implicitly anchors the regexes at both ends (^regex$).

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SELinux type transition rule not working

[Simon Sekidde]

- Original Message -
> From: "Ian Pilcher" 
> To: "Simon Sekidde" 
> Cc: "Systemd" , seli...@tycho.nsa.gov, 
> lenn...@poettering.net
> Sent: Friday, March 3, 2017 10:44:18 AM
> Subject: Re: [systemd-devel] SELinux type transition rule not working
> 
> On 03/02/2017 09:13 AM, Simon Sekidde wrote:
> > I assume this would be a pid file?
> 
> You assume correctly.
> 
> > If so then what you are probably looking for is a filename_trans rule
> > and will require a new interface in squid.if for this.
> >
> > Try something like
> >
> > interface(`squid_filetrans_named_content',` gen_require(`
> > type_squid_var_run_t; ')
> >
> > files_pid_filetrans($1, squid_var_run_t, dir, "squozy") ')
> 
> Not sure where squid came from.  The service is one of my own making
> called "squoxy" (short for "Squeezebox proxy").  Its purpose is to
> forward Squeezebox discovery broadcast packets from one network to
> another.
> 

Sorry I must have been doing something in the squid policy while I was 
responding to this... 

> So I assume that I would need to add something like this to my policy
> module:
> 
>files_pid_filetrans(var_run_t, squoxy_var_run_t, dir, "squoxy")
> 
> (I'm guessing at what to put in for $1.)
> 

files_pid_filetrans(squoxy_t, squoxy_var_run_t, dir, "squoxy") 

Files created by the squoxy_t processes in the var_run_t directory will be 
created with the squoxy_var_run_t label

> >> Hmm, so the relevant code in systemd actually labels the dir after
> >> creating it after an selinux database lookup, so from our side all
> >> should be good:
> >>
> >> https://github.com/systemd/systemd/blob/master/src/core/execute.c#L1857
> >>
> >>
> >>(specifically, we all mkdir_p_label() instead of plain mkdir_p()
>  >> there)
> 
> And this is working now, presumably after a reboot?  I do so love
> non-deterministic computers.  :-/
> 
> --
> 
> Ian Pilcher arequip...@gmail.com
>  "I grew up before Mark Zuckerberg invented friendship" 
> 
> 



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SELinux type transition rule not working

[Ian Pilcher]

On 03/02/2017 09:13 AM, Simon Sekidde wrote:

I assume this would be a pid file?


You assume correctly.


If so then what you are probably looking for is a filename_trans rule
and will require a new interface in squid.if for this.

Try something like

interface(`squid_filetrans_named_content',` gen_require(`
type_squid_var_run_t; ')

files_pid_filetrans($1, squid_var_run_t, dir, "squozy") ')


Not sure where squid came from.  The service is one of my own making
called "squoxy" (short for "Squeezebox proxy").  Its purpose is to
forward Squeezebox discovery broadcast packets from one network to
another.

So I assume that I would need to add something like this to my policy
module:

  files_pid_filetrans(var_run_t, squoxy_var_run_t, dir, "squoxy")

(I'm guessing at what to put in for $1.)


Hmm, so the relevant code in systemd actually labels the dir after
creating it after an selinux database lookup, so from our side all
should be good:

https://github.com/systemd/systemd/blob/master/src/core/execute.c#L1857


(specifically, we all mkdir_p_label() instead of plain mkdir_p()

>> there)

And this is working now, presumably after a reboot?  I do so love
non-deterministic computers.  :-/

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SELinux type transition rule not working

[Ian Pilcher]

On 03/02/2017 12:12 AM, Jason Zaman wrote:

On Wed, Mar 01, 2017 at 05:51:01PM -0600, Ian Pilcher wrote:

On 03/01/2017 05:28 PM, Ian Pilcher wrote:

Per Lennart's response, systemd *should* be honoring the file context
rules when creating the directory.  It's almost as if the directory is
being created with the proper context, but something is changing it
after the fact.  I have absolutely no idea what that might be, though.


Try using auditd to get details on everything going on in there:
auditctl -w /var/run/squoxy -p rwa -k watchsquoxy

then start things up and get everything matching with:
ausearch -k watchsquoxy


And wouldn't you know ... I can't reproduce the behavior now.  Sheesh!
Must be one of these fancy new quantum computers.  (Something about
rebooting 3 times comes to mind.)


also, not sure if it was just weirdness in your email formatting, but
you dont need the ^ at the front of an fcontext:
^/var/run/squoxy


Does SELinux add an implicit ^ at the beginning of each expression?
Otherwise, wouldn't /run/squoxy(/.*)? also match /foo/run/squoxy?  (Not
necessarily likely, but ...)

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to use machinectl to get a running centos container?

[Lennart Poettering]

On Sat, 04.03.17 01:38, Daurnimator (q...@daurnimator.com) wrote:

> On 3 March 2017 at 20:58, Lennart Poettering  wrote:
> > On Fri, 03.03.17 12:34, Daurnimator (q...@daurnimator.com) wrote:
> >
> >> I'm trying to set up a centos 7 container with machinectl.
> >> I've tried to run:
> >>
> >> machinectl pull-raw --verify=no
> >> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1701.raw.tar.gz
> >
> > Hmm, what is a ".raw.tar.gz" file? That suffix makes no sense to me...
> 
> *shrugs* it's what I saw available for download from
> http://cloud.centos.org/centos/7/images/
> 
> Apparently it's a gziped tar with a single file inside:
> CentOS-7-x86_64-GenericCloud-20170131_01.raw
> This .raw file is a disk image.

That appears a bit redundant, and importd/machinectl pull-raw is not
able to handle this.


> > We support raw disk images and tarballs with OS trees in them, both
> > compressed and non-compressed.
> >
> > There's currently a safety limit against overly large images enforced,
> > of 8GiB. If the indicated image is larger than that, and that's
> > intended we should probably bump this safety limit substantially (32G?
> > 64G?), please file a github issue asking for this if this is the
> > case. Or even better prep a PR, the fix is trivial:
> >
> > https://github.com/systemd/systemd/blob/master/src/import/pull-job.c#L530
> 
> Looks like it's *equal* to the limit.
> 
> Before I make a PR here, am I going about running a centos container
> with machinectl the best way here?
> How are other people doing this?

I don't think many people are using CentOS caontainers with
nspawn... That said, there's a good chance that it works OKish.

Note that "machinectl pull-raw" is just a helper to make downloading
easy. But if you have images in weird formats, you can download them
and place them in /var/lib/machines (with the .raw suffix), and
machined/nspawn is happy. It doesn't really matter how the image gets
there as long as it gets there, and "machinectl pull-raw" is just one
way.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to use machinectl to get a running centos container?

[Daurnimator]

On 3 March 2017 at 20:58, Lennart Poettering  wrote:
> On Fri, 03.03.17 12:34, Daurnimator (q...@daurnimator.com) wrote:
>
>> I'm trying to set up a centos 7 container with machinectl.
>> I've tried to run:
>>
>> machinectl pull-raw --verify=no
>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1701.raw.tar.gz
>
> Hmm, what is a ".raw.tar.gz" file? That suffix makes no sense to me...

*shrugs* it's what I saw available for download from
http://cloud.centos.org/centos/7/images/

Apparently it's a gziped tar with a single file inside:
CentOS-7-x86_64-GenericCloud-20170131_01.raw
This .raw file is a disk image.


>> This downloads the image, but then dies with:
>>
>> File overly large, refusing
>> Failed to retrieve image file. (Wrong URL?)
>> Exiting.
>
> How large is the file?

  - The .gz is 581M
  - The .tar is 8.1G
  - The .raw is 8.0G (8388608 K)

>> Is there some other way I should be doing this?
>
> We support raw disk images and tarballs with OS trees in them, both
> compressed and non-compressed.
>
> There's currently a safety limit against overly large images enforced,
> of 8GiB. If the indicated image is larger than that, and that's
> intended we should probably bump this safety limit substantially (32G?
> 64G?), please file a github issue asking for this if this is the
> case. Or even better prep a PR, the fix is trivial:
>
> https://github.com/systemd/systemd/blob/master/src/import/pull-job.c#L530

Looks like it's *equal* to the limit.

Before I make a PR here, am I going about running a centos container
with machinectl the best way here?
How are other people doing this?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to use machinectl to get a running centos container?

[Lennart Poettering]

On Fri, 03.03.17 12:34, Daurnimator (q...@daurnimator.com) wrote:

> I'm trying to set up a centos 7 container with machinectl.
> I've tried to run:
> 
> machinectl pull-raw --verify=no
> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1701.raw.tar.gz

Hmm, what is a ".raw.tar.gz" file? That suffix makes no sense to me...

> This downloads the image, but then dies with:
> 
> File overly large, refusing
> Failed to retrieve image file. (Wrong URL?)
> Exiting.

How large is the file?

> Is there some other way I should be doing this?

We support raw disk images and tarballs with OS trees in them, both
compressed and non-compressed.

There's currently a safety limit against overly large images enforced,
of 8GiB. If the indicated image is larger than that, and that's
intended we should probably bump this safety limit substantially (32G?
64G?), please file a github issue asking for this if this is the
case. Or even better prep a PR, the fix is trivial:

https://github.com/systemd/systemd/blob/master/src/import/pull-job.c#L530

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel