Re: [systemd-devel] how to debug failures when trying to lock down services

2017-12-01 Thread Michael Biebl 
2017-11-30 18:24 GMT+01:00 Lennart Poettering :
> On Do, 30.11.17 10:35, Mantas Mikulėnas (graw...@gmail.com) wrote:
>
>> Then I'm guessing ProtectSystem=strict overrides ReadWritePaths and makes
>> /var/log read-only...
>
> Hmm, it does? It really shouldn't.
>
> I thought the issues were mostly around InaccessiblePaths= not
> permitting exclusions, not about ProtectSystem/ReadOnlyPaths...
>
> Have a link?

I think I can reproduce that with v235. I think it works with git
master, but I need to verify that.




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd Journald and audit logging causing journal issues

2017-12-01 Thread Lennart Poettering 
On Fr, 01.12.17 12:19, Brad Zynda (bradley.v.zy...@nasa.gov) wrote:

> 
> 
> On 12/01/2017 12:11 PM, Lennart Poettering wrote:
> > On Fr, 01.12.17 09:05, Brad Zynda (bradley.v.zy...@nasa.gov) wrote:
> > 
> >> Hey Lennart,
> > 
> > Heya,
> > 
> >> Just wanted to get your thoughts on this before we break the link..
> > 
> > On what precisely? I am not sure what the original issue is, can you
> > summarize this briefly here?
> 
> Absolutely, here is the previous email chain:

Ah, completely forgot about that thread...

I am still wondering: why does auditd log to the journal (or syslog or
stdout/stderr) at all? It maintains its own log record database to my
knowledge. Moreover, journald is pulls audit data directly from the
kernel anyway, hence there's no need to also push data in from auditd
anyway

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] Systemd Journald and audit logging causing journal issues

2017-12-01 Thread Brad Zynda 


On 12/01/2017 12:31 PM, Lennart Poettering wrote:
> On Fr, 01.12.17 12:19, Brad Zynda (bradley.v.zy...@nasa.gov) wrote:
> 
>>
>>
>> On 12/01/2017 12:11 PM, Lennart Poettering wrote:
>>> On Fr, 01.12.17 09:05, Brad Zynda (bradley.v.zy...@nasa.gov) wrote:
>>>
 Hey Lennart,
>>>
>>> Heya,
>>>
 Just wanted to get your thoughts on this before we break the link..
>>>
>>> On what precisely? I am not sure what the original issue is, can you
>>> summarize this briefly here?
>>
>> Absolutely, here is the previous email chain:
> 
> Ah, completely forgot about that thread...
> 
> I am still wondering: why does auditd log to the journal (or syslog or
> stdout/stderr) at all? It maintains its own log record database to my
> knowledge. Moreover, journald is pulls audit data directly from the
> kernel anyway, hence there's no need to also push data in from auditd
> anyway
> 
> Lennart
> 
Well here is what Steve has said on it:



On Friday, December 1, 2017 8:17:58 AM EST Brad Zynda wrote:
> Hey Steve,
>
> Just wanted to follow up on this and say we are still seeing services
> across the board that have:
>
> Warning: Journal has been rotated since unit was started. Log output is
> incomplete or unavailable
>
> basically created a script to check all unit file services/targets and
> grep status -l for Journal, it is effecting a large range of
> service.target's, service.service's and service.socket's
>
> If we restart the service or reboot we no longer see those messages
> about journal and everything appears to run as expected.

I have never looked at journald code and have no idea how it works or
why it
cares about audit events. My advice last email was to break the link if its
causing problems.

-Steve


> On 10/19/2017 04:13 PM, Steve Grubb wrote:
>> On Thursday, October 19, 2017 1:08:22 PM EDT Brad Zynda wrote:
> grep perm_mod /etc/audit/audit.rules
> -a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F
auid>=1000
> -F auid!=4294967295 -k perm_mod
> -a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F
auid>=1000
> -F auid!=4294967295 -k perm_mod
> -a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F
> auid>=1000 -F auid!=4294967295 -k perm_mod
> -a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F
> auid>=1000 -F auid!=4294967295 -k perm_mod
> -a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S
> removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F
> auid!=4294967295 -k perm_mod
> -a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S
> removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F
> auid!=4294967295 -k perm_mod
>
> grep delete /etc/audit/audit.rules
> -a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat
> -F auid>=1000 -F auid!=4294967295 -k delete
> -a always,exit -F arch=b32 -S unlink -S unlinkat -S rename -S renameat
> -F auid>=1000 -F auid!=4294967295 -k delete
> -a always,exit -F arch=b64 -S init_module -S delete_module -k modules
> -a always,exit -F arch=b32 -S init_module -S delete_module -k modules

 These rules are well formed. Meaning no obvious holes that would cause
 unintended events. The other ausearch/aureport commands I gave you
 should
 show you what is causing the events and to which files. This
information
 may be used to create some kind of "never" rule that limits what gets
 audited. If you do create some exclusion rule, it needs to be above the
 perm_mod rules because audit is a "first match wins" system.

 -Steve

 -Steve
>>>
>>> Here is a peak report (at least in the last 24 hours) didnt include the
>>
>>> file summaries as that would make this email HUGE:
>> Well, the idea is to look for something that's getting hit a lot. What it
>> sounds like is that things are getting deleted and modified quite a bit
>> all
>> over the place. Does the executable report show a pattern such as one
>> application doing a lot? For example, with the rule you have, doing a yum
>> update will delete a whole lot of stuff and modify a whole lot of stuff.
>>
>> Its possible to put exceptions in the rules so that one program does not
>> flood the logs. But looking at the quantities below, the audit system can
>> easily handle that.
>>
>> Its also possible to exclude directories from auditing if the pattern is
>> that you have a daemon receiving and modifying files and then deleting
>> them. You should look at the executables & files and see if you can do
>> with auditing what they are doing because its not interesting.
>>
>> If this is causing you problems on the journald side where its causing
>> other tasks to fail. Then I'd break the link between auditd and journald.
>> The amount of event you show is highish but well within range of what
>> auditd can do. Just make sure flush is set to incremental_async and freq
>> is 100 or 200. You should

Re: [systemd-devel] Systemd Journald and audit logging causing journal issues

2017-12-01 Thread Brad Zynda 


On 12/01/2017 12:11 PM, Lennart Poettering wrote:
> On Fr, 01.12.17 09:05, Brad Zynda (bradley.v.zy...@nasa.gov) wrote:
> 
>> Hey Lennart,
> 
> Heya,
> 
>> Just wanted to get your thoughts on this before we break the link..
> 
> On what precisely? I am not sure what the original issue is, can you
> summarize this briefly here?

Absolutely, here is the previous email chain:



Hello Everyone,

I am sending along an issue brought to the systemd-journald dev list
initially:



On 10/02/2017 11:40 AM, Lennart Poettering wrote:
> On Mo, 02.10.17 11:25, Brad Zynda (bradley.v.zy...@nasa.gov) wrote:
>
>> Sep 28 13:50:03 server systemd-journal[565]: Suppressed 73244 messages
>> from /system.slice/auditd.service
>
> The question is: why does auditd even log to the journal?
>
>> Now we are required to have full audit rules and does this look like at
>> rate limiting issue or an issue of journal not able to handle the
>> traffic to logging?
>
> journald detected that it got flooded with too many messages in too
> short a time from auditd. if this happens then something is almost
> certainly off with auditd, as auditd is not supposed to flood journald
> with messages, after all it maintains its own auditing log database.
>
> Please ping the auditd folks for help
>
> Lennart
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel





Hey Everyone,

Not sure if this is a bug so:

systemctl status -l systemd-journald.service
● systemd-journald.service - Journal Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service;
static; vendor preset: disabled)
   Active: active (running) since Tue 2017-09-26 20:01:16 UTC; 5 days ago
 Docs: man:systemd-journald.service(8)
   man:journald.conf(5)
 Main PID: 565 (systemd-journal)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-journald.service
   └─565 /usr/lib/systemd/systemd-journald

Sep 28 13:50:03 server systemd-journal[565]: Suppressed 73244 messages
from /system.slice/auditd.service
Sep 28 13:51:03 server systemd-journal[565]: Suppressed 98979 messages
from /system.slice/auditd.service
Sep 28 13:52:03 server systemd-journal[565]: Suppressed 109433 messages
from /system.slice/auditd.service
Sep 28 13:53:03 server systemd-journal[565]: Suppressed 99788 messages
from /system.slice/auditd.service
Sep 28 13:54:03 server systemd-journal[565]: Suppressed 111605 messages
from /system.slice/auditd.service
Sep 28 13:55:03 server systemd-journal[565]: Suppressed 111591 messages
from /system.slice/auditd.service
Sep 28 13:56:03 server systemd-journal[565]: Suppressed 107947 messages
from /system.slice/auditd.service
Sep 28 13:57:51 server systemd-journal[565]: Suppressed 32760 messages
from /system.slice/auditd.service
Sep 28 17:21:40 server systemd-journal[565]: Suppressed 210 messages
from /system.slice/auditd.service
Oct 01 02:16:01 server systemd-journal[565]: Suppressed 1333 messages
from /system.slice/auditd.service



journalctl --verify
PASS: /run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-0097f6c7-0005596b745b4d1c.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-0096a587-00055966f35ae59a.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-009554f1-000559629c4cdb7e.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-00940591-0005595e1811a2d1.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-0092b500-00055959f2de5ede.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-00916479-0005595573137b74.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-00901337-00055950d80cc3d8.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-008ec2fb-0005594cad14b07a.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-008d7373-0005594838683e58.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-008c238e-00055943fe2072e3.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-008ad1d9-0005593ff64a4f69.journal
PASS:
/run/log/journal/d28b0080ffe0432a974f36e4fb4bfa9b/system@0d49221d68d04ef0b95d8203c5e96a46-00897f32-0005593e18c5758b.journal


journalctl --disk-usage
Archived and active journals take up 1.1G on disk.


Initially we saw:
16733 PATH
5070 SYSCALL
5024 CWD
3765 AVC
323 CRYPTO_KEY_USER
223 USER_START

Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

2017-12-01 Thread Lennart Poettering 
On Fr, 01.12.17 13:42, Pekka Paalanen (ppaala...@gmail.com) wrote:

> > > > This is racy, as the session ID is not really reliably predictable,
> > > > and is synthesized in different contexts in different ways, for
> > > > example depnding on whether audit is enabled in the kernel it might be
> > > > session-1.scope rather than session-c1.scope.  
> 
> > > If we could determine the bug doesn't exist anymore, that would be
> > > awesome and I could just drop this.
> 
> Hi Lennart,
> 
> taking a step back, the session-c1.scope directive is definitely not
> wanted and we should drop it. We should also use a custom PAM name
> setup. If we do that, is the service file otherwise good for
> guaranteeing:
> 
> - a full user session setup (I presume we want it), specifically
>   XDG_RUNTIME_DIR being set up
> 
> - running exclusively on a VT that is made current

This really depends on how weston sets up a VT. I really don't know
Weston and what it does. 

> - access to DRM and input devices via logind

So, I can't comment on Weston really.

Here are brief (and possibly slightly out-of-date, but probably not)
notes on how to write display managers with logind:

https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/

> so that all these are already in place by the time the Weston process
> is started?
> 
> As you can see from Martyn below, the first issue that prevented Weston
> from running was that XDG_RUNTIME_DIR was not set. Furthermore, this
> failure did not occur always, sometimes things just worked as we
> expected.

So, as long as weston runs from a PAM enabled service (and its PAM
snippet pulls in pam_systemd) all should be good and race-free: as the
PAM session is set up XDG_RUNTIME_DIR will be made available and the
systemd --user instance is invoked in the background.

What currently is not supported is to run things independently of any
session, i.e. run weston as systemd --user service with nothing that
creates a session in the first place. In that case XDG_RUNTIME_DIR
will not be set up, and no devices are made available to weston...

> > > > > +# Set up a full user session for the user, required by Weston.
> > > > > +PAMName=login
> > > > 
> > > > Piggy-backing on "login" is a bad idea. "login" is a text tool, and
> > > > thus the PAM rules for it usually pull in some TTY specific PAM
> > > > modules. YOu shoudl really use your own PAM fragment here, and
> > > > configure only the bits you need.  
> > >   
> > 
> > Oh, so could it just be that we needed something other than
> > "PAMName=login"?
> 
> What are they key bits in the PAM configuration we must have, and are
> there any often used bits we must not have to avoid the race Martyn
> describes?

well, pam_systemd needs to be pulled in from it, that's the most
important thing. A PAM snippet that pulls in pam_systemd means you get
a session allcoated in logind, which in turn sets up XDG_RUNTIME_DIR
for you.

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] Systemd Journald and audit logging causing journal issues

2017-12-01 Thread Lennart Poettering 
On Fr, 01.12.17 09:05, Brad Zynda (bradley.v.zy...@nasa.gov) wrote:

> Hey Lennart,

Heya,

> Just wanted to get your thoughts on this before we break the link..

On what precisely? I am not sure what the original issue is, can you
summarize this briefly here?

> also can you provide proper direction or a howto for breaking the link
> between auditd and journald?

auditd and journald aren't linked. Both get the audit data directly
from the kernel. Either can run fine without the other. To turn off
that journald picks up audit data from the kernel use "systemctl mask
systemd-journald-audit.socket" (and reboot), which will turn off all
audit data collection by journald.

But again, I am not entirely sure what the original issue is?

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] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-12-01 Thread Lennart Poettering 
On Fr, 01.12.17 12:04, Olaf Hering (o...@aepfle.de) wrote:

> Am Fri, 1 Dec 2017 10:21:46 +
> schrieb Wei Liu :
> 
> > In Olaf's case, he cares about knowing whether the domain runs the
> > controlling toolstack, he doesn't care about if it is the hardware
> > domain or not, so my conclusion was using that flag was wrong.
> 
> I think this is not entirely accurate. Right now the term "dom0" is 
> a mix of "has access to host (IO) hardware" and "runs the toolstack".
> 
> ConditionVirtualization= today lacks such details as well.
> "xen" means domU, and "none" is dom0, simply to handle "dom0" like "native"
> so that all services that want access to "host hardware" can start.
> 
> One could argue that passing a PCI device to a domU may also require
> .service files to manage that PCI device in some way. The specifc case
> which triggered all the suggested changes was smartd, which is not
> supposed to run in "VMs". If a SATA card is provided to a domU it may
> be a good idea to monitor the attached disks as well.
> 
> So in some way Jan is correct with his suggestion to use XENFEAT_dom0
> instead of "control_d". I will do some research about when it became available
> and update the patch description.

To make this clear: systemd is only interested in a very high-level
view on things: all it wants to know if we are payload of some kind of
virtualization, or not. We aren't interested in details, and what kind
of virtualization logic Xen precisely deploys is an implementation
detail from our point of view, that we aren't interested in. If
services need to know in all detail what kind of system they run on,
then ConditionVirtualization=/AssertVirtualization= is really not for
them, and they should just run their own code, and figure out things
on their own.

I don't care much where precisely the line is drawn, when a Xen
environment is considered "host" and when "guest", I'll let you guys
figure that out. Only for the latter ConditionVirtualization=guest
should hold, for the latter it should not.

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] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-12-01 Thread Jan Beulich 
>>> Wei Liu  12/01/17 1:30 PM >>>
>On Fri, Dec 01, 2017 at 05:23:16AM -0700, Jan Beulich wrote:
>> >>> On 01.12.17 at 13:15,  wrote:
>> > On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote:
>> >> >>> On 01.12.17 at 12:48,  wrote:
>> >> > Suppose at one point we split hardware domain and control domain, which
>> >> > one will you call Dom0? Which one will get the flag?
>> >> 
>> >> There can only be one hardware domain, which will continue to
>> >> be the one getting XENFEAT_dom0. There could be any number
>> >> of control domains (perhaps with some coordination between
>> >> them).
>> > 
>> > Right. So XENFEAT_dom0 is not really what Olaf needs. 
>> 
>> Sigh. What does "has access to all the hardware" translate to
>> for you?
>
>That would mean hardware domain.
>
>But Olaf needs to know if some of the services like xenconsoled or
>xenstored should be started, and if some of the special file systems
>should be mounted, right? Those aren't tied to hardware in anyway. In my
>view that's the responsibility of the toolstack control domain.
>
>Can you point me to the start of your discussion with Olaf so that I can
>check what the disagreement between you and Olaf is about?

The start of the discussion is the root of this thread. Olaf somewhere in
the middle pointed to another discussion which you appear to have been
involved in.

I'm also not sure there's actual disagreement here - I was merely pointing
out that strictly following what was written in the description of the patch
there may not be a need to consult /proc/xen, and hence no need to
mount it early.

Jan

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

Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-12-01 Thread Olaf Hering 
On Fri, Dec 01, Wei Liu wrote:

> What information do you need? For a moment let's skip using the fuzzy
> "Dom0" term and try to be precise. Like "I would like to know if that
> domain has access to all hardware" or something else.

That depends on the .service files. This is the list of openSUSE Tumbleweed:

dev-hugepages.mount:ConditionVirtualization=!private-users
haveged.service:ConditionVirtualization=!container
hv_fcopy_daemon.service:ConditionVirtualization=microsoft
hv_kvp_daemon.service:ConditionVirtualization=microsoft
hv_vss_daemon.service:ConditionVirtualization=microsoft
irqd.service:ConditionVirtualization=!container
ksm.service:ConditionVirtualization=no
lxcfs.service:ConditionVirtualization=!container
mcelog.service:ConditionVirtualization=false
ntp-wait.service:ConditionVirtualization=!container
ntpd.service:ConditionVirtualization=!container
rng-tools.service:ConditionVirtualization=!container
smartd.service:ConditionVirtualization=false
sys-fs-fuse-connections.mount:ConditionVirtualization=!private-users
systemd-random-seed.service:ConditionVirtualization=!container
systemd-timesyncd.service:ConditionVirtualization=!container
vgauthd.service:ConditionVirtualization=vmware
vmblock-fuse.service:ConditionVirtualization=vmware
vmtoolsd.service:ConditionVirtualization=vmware
xendriverdomain.service:ConditionVirtualization=xen

I think the relevant services are ksm,mcelog and smartd. Each one likely
wants the "hardware domain" rather than the "toolstack domain". IMO what
systemd today sees as "dom0" should be set based on "XENFEAT_dom0".

Olaf


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

Re: [systemd-devel] Systemd Journald and audit logging causing journal issues

2017-12-01 Thread Brad Zynda 
Hey Lennart,

Just wanted to get your thoughts on this before we break the link..

also can you provide proper direction or a howto for breaking the link
between auditd and journald?

Thanks,
Brad

On Friday, December 1, 2017 8:17:58 AM EST Brad Zynda wrote:
> Hey Steve,
>
> Just wanted to follow up on this and say we are still seeing services
> across the board that have:
>
> Warning: Journal has been rotated since unit was started. Log output is
> incomplete or unavailable
>
> basically created a script to check all unit file services/targets and
> grep status -l for Journal, it is effecting a large range of
> service.target's, service.service's and service.socket's
>
> If we restart the service or reboot we no longer see those messages
> about journal and everything appears to run as expected.

I have never looked at journald code and have no idea how it works or
why it
cares about audit events. My advice last email was to break the link if its
causing problems.

-Steve


> On 10/19/2017 04:13 PM, Steve Grubb wrote:
>> On Thursday, October 19, 2017 1:08:22 PM EDT Brad Zynda wrote:
> grep perm_mod /etc/audit/audit.rules
> -a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F
auid>=1000
> -F auid!=4294967295 -k perm_mod
> -a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F
auid>=1000
> -F auid!=4294967295 -k perm_mod
> -a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F
> auid>=1000 -F auid!=4294967295 -k perm_mod
> -a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F
> auid>=1000 -F auid!=4294967295 -k perm_mod
> -a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S
> removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F
> auid!=4294967295 -k perm_mod
> -a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S
> removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F
> auid!=4294967295 -k perm_mod
>
> grep delete /etc/audit/audit.rules
> -a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat
> -F auid>=1000 -F auid!=4294967295 -k delete
> -a always,exit -F arch=b32 -S unlink -S unlinkat -S rename -S renameat
> -F auid>=1000 -F auid!=4294967295 -k delete
> -a always,exit -F arch=b64 -S init_module -S delete_module -k modules
> -a always,exit -F arch=b32 -S init_module -S delete_module -k modules

 These rules are well formed. Meaning no obvious holes that would cause
 unintended events. The other ausearch/aureport commands I gave you
 should
 show you what is causing the events and to which files. This
information
 may be used to create some kind of "never" rule that limits what gets
 audited. If you do create some exclusion rule, it needs to be above the
 perm_mod rules because audit is a "first match wins" system.

 -Steve

 -Steve
>>>
>>> Here is a peak report (at least in the last 24 hours) didnt include the
>>
>>> file summaries as that would make this email HUGE:
>> Well, the idea is to look for something that's getting hit a lot. What it
>> sounds like is that things are getting deleted and modified quite a bit
>> all
>> over the place. Does the executable report show a pattern such as one
>> application doing a lot? For example, with the rule you have, doing a yum
>> update will delete a whole lot of stuff and modify a whole lot of stuff.
>>
>> Its possible to put exceptions in the rules so that one program does not
>> flood the logs. But looking at the quantities below, the audit system can
>> easily handle that.
>>
>> Its also possible to exclude directories from auditing if the pattern is
>> that you have a daemon receiving and modifying files and then deleting
>> them. You should look at the executables & files and see if you can do
>> with auditing what they are doing because its not interesting.
>>
>> If this is causing you problems on the journald side where its causing
>> other tasks to fail. Then I'd break the link between auditd and journald.
>> The amount of event you show is highish but well within range of what
>> auditd can do. Just make sure flush is set to incremental_async and freq
>> is 100 or 200. You should be OK.
>>
>> -Steve
>>
>>> Key Summary Report
>>> ===
>>> total  key
>>> ===
>>> 8170  perm_mod
>>> 5390  delete
>>> 1073  access
>>> 56  time-change
>>> 26  session
>>> 12  privileged
>>> 7  logins
>>>
>>>
>>> Syscall Summary Report
>>> ==
>>> total  syscall
>>> ==
>>> 4250  fchmodat
>>> 1613  chmod
>>> 831  fchmod
>>> 521  fchown
>>> 97  chown
>>> 12  setxattr
>>>
>>>
>>> Syscall Summary Report
>>> ==
>>> total  syscall
>>> ==
>>> 2887  unlink
>>> 2189  rename
>>> 186  unlinkat
>>>
>>>
>>> so from the list the top 2 in each perm_mod and delete from the above
>>> list seem to be the

Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-12-01 Thread Olaf Hering 
Am Fri, 1 Dec 2017 12:29:24 +
schrieb Wei Liu :

> But Olaf needs to know if some of the services like xenconsoled or
> xenstored should be started, and if some of the special file systems
> should be mounted, right? Those aren't tied to hardware in anyway. In my
> view that's the responsibility of the toolstack control domain.

No, I did not intent to make use of ConditionVirtualization= in the
xen*.service files in tools/hotplug/Linux/. That variable can not be used
for this purpose, and the patch would not change that.

In case you refer to the "proc-xen.mount" change from a few days/weeks ago,
this was all about avoiding the error when xenfs becomes an "API filesystem".
With this suggested change the existing "proc-xen.mount units would not fail
anymore because /proc/xen is added to the ignore list.

Olaf


pgp7kFBMS_k21.pgp
Description: Digitale Signatur von OpenPGP
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-12-01 Thread Jan Beulich 
>>> On 01.12.17 at 13:15,  wrote:
> On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote:
>> >>> On 01.12.17 at 12:48,  wrote:
>> > Suppose at one point we split hardware domain and control domain, which
>> > one will you call Dom0? Which one will get the flag?
>> 
>> There can only be one hardware domain, which will continue to
>> be the one getting XENFEAT_dom0. There could be any number
>> of control domains (perhaps with some coordination between
>> them).
> 
> Right. So XENFEAT_dom0 is not really what Olaf needs. 

Sigh. What does "has access to all the hardware" translate to
for you?

Jan

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

Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-12-01 Thread Jan Beulich 
>>> On 01.12.17 at 12:48,  wrote:
> Suppose at one point we split hardware domain and control domain, which
> one will you call Dom0? Which one will get the flag?

There can only be one hardware domain, which will continue to
be the one getting XENFEAT_dom0. There could be any number
of control domains (perhaps with some coordination between
them).

Jan

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

Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

2017-12-01 Thread Pekka Paalanen 
On Thu, 30 Nov 2017 11:16:19 +
Martyn Welch  wrote:

> On Thu, 2017-11-30 at 12:09 +0200, Pekka Paalanen wrote:
> > On Wed, 29 Nov 2017 19:05:07 +0100
> > Lennart Poettering  wrote:
> >   
> > > On Di, 28.11.17 12:14, Pekka Paalanen (ppaala...@gmail.com) wrote:
> > >   
> > > > +
> > > > +[Unit]
> > > > +Description=Weston, a Wayland compositor, as a system service
> > > > +Documentation=man:weston(1) man:weston.ini(5)
> > > > +Documentation=http://wayland.freedesktop.org/
> > > > +
> > > > +# Make sure we are started after logins are permitted.
> > > > +After=systemd-user-sessions.service
> > > > +
> > > > +# If Plymouth is used, we want to start when it is on its way out.
> > > > +After=plymouth-quit-wait.service
> > > > +
> > > > +# D-Bus is necessary for contacting logind. Logind is required.
> > > > +Wants=dbus.socket
> > > > +After=dbus.socket
> > > > +
> > > > +# This scope is created by pam_systemd when logging in as the user.
> > > > +# This directive is a workaround to a systemd bug, where the setup of 
> > > > the
> > > > +# user session by PAM has some race condition, possibly leading to a 
> > > > failure.
> > > > +# See README for more details.
> > > > +After=session-c1.scope
> > > 
> > > Hmm, what is this about?
> > > 
> > > This is racy, as the session ID is not really reliably predictable,
> > > and is synthesized in different contexts in different ways, for
> > > example depnding on whether audit is enabled in the kernel it might be
> > > session-1.scope rather than session-c1.scope.  

> > If we could determine the bug doesn't exist anymore, that would be
> > awesome and I could just drop this.

Hi Lennart,

taking a step back, the session-c1.scope directive is definitely not
wanted and we should drop it. We should also use a custom PAM name
setup. If we do that, is the service file otherwise good for
guaranteeing:

- a full user session setup (I presume we want it), specifically
  XDG_RUNTIME_DIR being set up

- running exclusively on a VT that is made current

- access to DRM and input devices via logind

so that all these are already in place by the time the Weston process
is started?

As you can see from Martyn below, the first issue that prevented Weston
from running was that XDG_RUNTIME_DIR was not set. Furthermore, this
failure did not occur always, sometimes things just worked as we
expected.

> 
> First off, apologies if I explained this badly when I attempted to
> explain the issue at FOSDEM, I'm still not convinced I truly understand
> what's happening here, but let's give it another go...
> 
> Testing of the product in the project mentioned by Pekka revealed that
> we would sometimes see Weston fail to boot. IIRC, in the order of 2 in
> 10 times when switching from an initial charging state (that the device
> would boot into when power was applied to the device without the power
> button being pressed) and the normal running state (when the power
> button was then pressed). The charging state is pretty much a small
> subset of the normal running state. From memory, the "xuser" session is
> not created in that state. The filtered logs that I was given:
> 
> 2017-01-05T14:08:19.41+00:00 XXX systemd-logind[315]: New seat
> seat0.
> 2017-01-05T14:08:19.672756+00:00 XXX systemd-logind[315]: Watching
> system buttons on /dev/input/event0 (power-gpio-keys)
> 2017-01-05T14:08:20.176354+00:00 XXX systemd[1]: Starting User Manager
> for UID 1000...
> 2017-01-05T14:08:20.394955+00:00 XXX systemd[1]: Starting Weston...
> 2017-01-05T14:08:21.867999+00:00 XXX systemd-logind[315]: New session c1
> of user xuser.
> 2017-01-05T14:08:21.915400+00:00 XXX systemd-logind[315]: Watching
> system buttons on /dev/input/event0 (power-gpio-keys)
> 2017-01-05T14:08:46.279480+00:00 XXX weston[403]: [14:08:46.157] fatal:
> environment variable XDG_RUNTIME_DIR is not set.
> 2017-01-05T14:08:46.421821+00:00 XXX systemd[1]: Failed to start Weston.
> 2017-01-05T14:08:46.471701+00:00 XXX systemd-logind[315]: Removed
> session c1.
> 2017-01-05T14:08:47.424030+00:00 XXX systemd[1]: Started User Manager
> for UID 1000.
> 2017-01-05T14:08:47.469949+00:00 XXX systemd-logind[315]: Failed to stop
> user service: Transaction is destructive.
> 2017-01-05T14:08:47.540518+00:00 XXX systemd-logind[315]: Failed to stop
> user slice: Transaction is destructive.
> 
> Debugging suggested that XDG_RUNTIME_DIR was not being created when it
> failed. There are 2 processes setting a PAMName, the failing Weston
> service and the user@.service (IIRC this gets called as part of user
> session creation, which I think was triggered by "User=xuser" in our
> weston.service). The user@.service has "PAMName=systemd-user" where as
> weston.service has "PAMName=login". When user@.service called PAM first
> everything worked as expected, if weston.service called PAM first it
> failed. This was our attempt at forcing the former rather than the
> latter.
> 
> > > > +# Set up a

Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-12-01 Thread Jan Beulich 
>>> On 01.12.17 at 11:21,  wrote:
> On Thu, Nov 30, 2017 at 01:35:45AM -0700, Jan Beulich wrote:
>> >>> On 30.11.17 at 09:23,  wrote:
>> > On Wed, Nov 29, Jan Beulich wrote:
>> > 
>> >> Ah, I see. But then still I don't see why at least on half way
>> >> recent Xen /sys/hypervisor/properties/features wouldn't have
>> >> the information you're after (and even more precise, because
>> >> down the road control domain and hardware domain may be
>> >> separate entities).
>> > 
>> > Per discussion in https://github.com/systemd/systemd/pull/6662, the
>> > feature bits should not be used for dom0 detection.
>> 
>> I can't seem to interpret that discussion the way you do. In fact
>> (as I've said before) using the feature flag is more reliable, as it
>> being set implies this is the hardware domain (rather than the
>> more fuzzy "control domain" implied by "control_d").
>> 
>> Wei, your comments there from Oct 27 and 30 are what I think
>> Olaf refers to. Could you clarify this?
>> 
> 
> Judging from the snippet here I don't quite understand what your
> disagreement is. You already said control domain and hardware domain
> could be separate entities in the future.
> 
> The XENFEAT_dom0 flag currently denotes hardware domain. It boils down
> to whether we want Dom0 to mean hardware domain, control domain or just
> "A domain that has domid 0".
> 
> In Olaf's case, he cares about knowing whether the domain runs the
> controlling toolstack, he doesn't care about if it is the hardware
> domain or not, so my conclusion was using that flag was wrong.

I understood it exactly the other way around: The question is
whether to treat things the same as without Xen:
"dom0 has to be handled as "no virtualization" because it has access to
 all hardware, all services depending on "native" have to run in dom0."
Sound like hardware domain to me, not control domain.

Jan

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

Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

2017-12-01 Thread Olaf Hering 
Am Fri, 1 Dec 2017 10:21:46 +
schrieb Wei Liu :

> In Olaf's case, he cares about knowing whether the domain runs the
> controlling toolstack, he doesn't care about if it is the hardware
> domain or not, so my conclusion was using that flag was wrong.

I think this is not entirely accurate. Right now the term "dom0" is 
a mix of "has access to host (IO) hardware" and "runs the toolstack".

ConditionVirtualization= today lacks such details as well.
"xen" means domU, and "none" is dom0, simply to handle "dom0" like "native"
so that all services that want access to "host hardware" can start.

One could argue that passing a PCI device to a domU may also require
.service files to manage that PCI device in some way. The specifc case
which triggered all the suggested changes was smartd, which is not
supposed to run in "VMs". If a SATA card is provided to a domU it may
be a good idea to monitor the attached disks as well.

So in some way Jan is correct with his suggestion to use XENFEAT_dom0
instead of "control_d". I will do some research about when it became available
and update the patch description.

Olaf


pgpexM37QzucI.pgp
Description: Digitale Signatur von OpenPGP
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel