Re: spamd Will Not Create unix:socket
On 28 Nov 2017, at 12:15, Colony.three wrote: [...] My God. It's full of stars! This fixed the spamass-milter problem. And it seems to be the correct way to fix the hundreds of other SELinux errors I have. You take this box, and put it through a magic tunnel and see if it looks right. If it does you put the box through another magic tunnel where it becomes a robot. Then turn on the robot. You don't need to know what the box really means nor what the magic tunnel does. Even though it's retail (one-by-one), it does fix it permanently. You can find slightly more detailed (but still generic) explanations of how to use audit2allow: http://danwalsh.livejournal.com/24750.html https://wiki.centos.org/HowTos/SELinux#head-faa96b3fdd922004cdb988c1989e56191c257c01 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-troubleshooting-fixing_problems#sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow The first is by the pre-eminent expert on SELinux. It also provides a strong clue as to where to look for human help with SELinux for people who are not paying RedHat. The surrounding documents for both the CentOS link and the RedHat link explain more of the details of what's inside the box and what the magic tunnels do. But yes, mandatory access control systems are inherently extremely complex and so you have a choice between mystified surrender, heavy education, or opaque boxes and magic tunnels.
Re: spamd Will Not Create unix:socket
>> First, copy and paste lines from the log into a file called thing0.log where
>> thing is a mnemonic name for what you're trying to enable. In this example,
>> thing is smartd
>>
>> root# cd; mkdir selinux; cd selinux
>> root# cat > smartd0.log
>> type=AVC msg=audit(1425551687.181:491): avc: denied { getattr } for
>> pid=20943 comm="smartd" path="/usr/lib64/libstdc++.so.6.0.19" dev="dm-1"
>> ino=134323340 scontext=system_u:system_r:fsdaemon_t:s0
>> tcontext=system_u:object_r:file_t:s0 tclass=file
>> type=AVC msg=audit(1425551687.181:492): avc: denied { execute } for
>> pid=20943 comm="smartd" path="/usr/lib64/libstdc++.so.6.0.19" dev="dm-1"
>> ino=134323340 scontext=system_u:system_r:fsdaemon_t:s0
>> tcontext=system_u:object_r:file_t:s0 tclass=file
>>
>> Next, see what allowing this would look like
>>
>> root# audit2allow < smartd0.log
>> #= fsdaemon_t ==
>> allow fsdaemon_t file_t:file { getattr execute };
>>
>> Assuming this looks vaguely sane, generate a loadable module that will allow
>> the access
>>
>> root# audit2allow -M smartd0 < smartd0.log
>>
>> And then load that module, using the command it just told you (annoyingly,
>> this step takes on the order of 10s)
>>
>> root# semodule -i smartd0.pp
My God. It's full of stars!
This fixed the spamass-milter problem. And it seems to be the correct way to
fix the hundreds of other SELinux errors I have.
You take this box, and put it through a magic tunnel and see if it looks right.
If it does you put the box through another magic tunnel where it becomes a
robot. Then turn on the robot.
You don't need to know what the box really means nor what the magic tunnel
does. Even though it's retail (one-by-one), it does fix it permanently.
Thank you Toby.
Re: spamd Will Not Create unix:socket
>> On 11/27/2017 10:34 PM, Colony.three wrote: >> ExecStartPre=/bin/chown -R spamd:spamd /run/spamassassin There's a root exploit for the "spamd" user in that last line. Assuming you got the tmpfiles.d thing working, you should delete those ExecStartPre commands. >>> >>> Can you explain further please? >>> If this is true, someone should tell Red Hat that their >>> /usr/lib/systemd/system/spamass-milter-root.service has the same problem. >>> >>> On 28.11.17 09:03, Michael Orlitzky wrote: >>> The "chown" command follows both symlinks and hardlinks by default. >>> >>> to be more precise, there is nothing like "following hard links" because >>> hard links are "the" files. >>> >>> When used with the "-R" flag, it only follows hardlinks, >>> >>> it recurses into /run/spamassassin, handling all files and directories >>> there, not following symlinks. >>> >>> but that can still >>> be abused by the "spamd" user. The first time "chown -R" gets executed, >>> you give ownership of /run/spamassassin to the "spamd" user. The second >>> (and third, ...) time that the service is started, the "spamd" user owns >>> that directory and can place a hard link in it pointing to a root-owned >>> file. The "chown" call will then give root's file to the "spamd" user. >>> >>> The simple workaround is to avoid the "-R" flag. in fact, we only need it >>> when we create /run/spamassassin so it gets owned by spamd. >>> >>> The exploit is trickier in this case because /run is on a tmpfs, and >>> because hard links can't cross filesystem boundaries. But I would bet >>> that you have something else sensitive in /run that can be used to gain >>> root. Interesting, thanks guys. I'd added the chown because I thought I needed it, but have now found that it's entirely unnecessary. (Someone should let RedHat know about their milter.service though -- I tried but can't get signed up for Bugzilla) FWIW here's what I think RedHat's spamassassin.service -should- look like. Works perfectly, unlike RedHat's version which does not create the socket directory, nor have Nice, nor security . [Unit] Description=Spamassassin daemon After=syslog.target network.target PartOf=spamassassin-update.service [Service] Type=forking EnvironmentFile=-/etc/sysconfig/spamassassin ExecStartPre=-/sbin/portrelease spamd # Create socket directory: RuntimeDirectory=spamassassin RuntimeDirectoryMode=770 ExecStart=/usr/bin/spamd --pidfile /run/spamassassin/spamd.pid $SPAMDOPTIONS Nice=5 StandardOutput=syslog StandardError=syslog Restart=always # Security PrivateTmp=yes InaccessibleDirectories=/bin /boot /home /media /mnt /opt /root /sbin /sys ReadOnlyDirectories=/lib /lib64 /usr CapabilityBoundingSet=~CAP_SYS_PTRACE DeviceAllow=/dev/null rw NoNewPrivileges=yes [Install] WantedBy=multi-user.target
Re: spamd Will Not Create unix:socket
On 11/27/2017 10:34 PM, Colony.three wrote: ExecStartPre=/bin/chown -R spamd:spamd /run/spamassassin There's a root exploit for the "spamd" user in that last line. Assuming you got the tmpfiles.d thing working, you should delete those ExecStartPre commands. Can you explain further please? If this is true, someone should tell Red Hat that their /usr/lib/systemd/system/spamass-milter-root.service has the same problem. On 28.11.17 09:03, Michael Orlitzky wrote: The "chown" command follows both symlinks and hardlinks by default. to be more precise, there is nothing like "following hard links" because hard links are "the" files. When used with the "-R" flag, it only follows hardlinks, it recurses into /run/spamassassin, handling all files and directories there, not following symlinks. but that can still be abused by the "spamd" user. The first time "chown -R" gets executed, you give ownership of /run/spamassassin to the "spamd" user. The second (and third, ...) time that the service is started, the "spamd" user owns that directory and can place a hard link in it pointing to a root-owned file. The "chown" call will then give root's file to the "spamd" user. The simple workaround is to avoid the "-R" flag. in fact, we only need it when we create /run/spamassassin so it gets owned by spamd. The exploit is trickier in this case because /run is on a tmpfs, and because hard links can't cross filesystem boundaries. But I would bet that you have something else sensitive in /run that can be used to gain root. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "One World. One Web. One Program." - Microsoft promotional advertisement "Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler
Re: spamd Will Not Create unix:socket
On 11/27/2017 10:34 PM, Colony.three wrote: >> ExecStartPre=/bin/chown -R spamd:spamd /run/spamassassin >> >> There's a root exploit for the "spamd" user in that last line. Assuming >> you got the tmpfiles.d thing working, you should delete those >> ExecStartPre commands. > > Can you explain further please? > > If this is true, someone should tell Red Hat that their > /usr/lib/systemd/system/spamass-milter-root.service has the same problem. > The "chown" command follows both symlinks and hardlinks by default. When used with the "-R" flag, it only follows hardlinks, but that can still be abused by the "spamd" user. The first time "chown -R" gets executed, you give ownership of /run/spamassassin to the "spamd" user. The second (and third, ...) time that the service is started, the "spamd" user owns that directory and can place a hard link in it pointing to a root-owned file. The "chown" call will then give root's file to the "spamd" user. The exploit is trickier in this case because /run is on a tmpfs, and because hard links can't cross filesystem boundaries. But I would bet that you have something else sensitive in /run that can be used to gain root.
Re: spamd Will Not Create unix:socket
>I am really trying to not turn off SELinux with this server, and only have
>this one showstopper error. But I don't know what to do with this gibberish:
Here's an extract from a page I wrote about SELinux (not currently published,
or I could just send you the link).
--->8---
This is where it can get a bit hairy. I recommend creating /root/selinux as a
scratchpad to work in, and as a record of what changes have been made.
First, copy and paste lines from the log into a file called thing0.log where
thing is a mnemonic name for what you're trying to enable. In this example,
thing is smartd
root# cd; mkdir selinux; cd selinux
root# cat > smartd0.log
type=AVC msg=audit(1425551687.181:491): avc: denied { getattr } for
pid=20943 comm="smartd" path="/usr/lib64/libstdc++.so.6.0.19" dev="dm-1"
ino=134323340 scontext=system_u:system_r:fsdaemon_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=file
type=AVC msg=audit(1425551687.181:492): avc: denied { execute } for
pid=20943 comm="smartd" path="/usr/lib64/libstdc++.so.6.0.19" dev="dm-1"
ino=134323340 scontext=system_u:system_r:fsdaemon_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=file
Next, see what allowing this would look like
root# audit2allow < smartd0.log
#= fsdaemon_t ==
allow fsdaemon_t file_t:file { getattr execute };
Assuming this looks vaguely sane, generate a loadable module that will allow
the access
root# audit2allow -M smartd0 < smartd0.log
And then load that module, using the command it just told you (annoyingly, this
step takes on the order of 10s)
root# semodule -i smartd0.pp
What you'll typically find is that whatever you were trying to do now fails at
the next step. For example, you might have just allowed getattr access, but the
next thing the program needs to do is open the file. Repeat the process with
thing1.log. This does get a bit annoying, but I don't think I've ever taken
more than about 3 or 4 steps.
Note that not everything forbidden by SELinux needs to be allowed. Quite often
programs will happily run, despite generating a few warnings in the log.
---8<---
Hope this helps!
Toby.
Re: spamd Will Not Create unix:socket
On 27 Nov 2017, at 22:45 (-0500), Colony.three wrote:
>> Is anyone using the unix:socket for spamaassassin's milter?
>> When I turned on SELinux, it will not let me change the group of the
>> spamass-milter socket. (/run/spamass-milter/postfix/sock)
>> /var/log/messages
>> spamass-milter: group option, chown: Operation not permitted
>> G**gle's baffled how to set SELinux to fix this.
>>
>> The policycoreutils-python package, in particular its audit2why and
>> audit2allow tools, are indispensable for diagnosing and solving SELinux
>> issues. A particular advantage they have over Google, Bing, or
>> StackOverflow is that they are designed specifically to diagnose and
>> solve SELinux problems and they work really fast...
audit2why -a gives just a haystack of problems, none of which reference
specific files, and all of which seem to be hysterics. I have so many things
to do that I can never learn SELinux coherently, and usually end up turning it
off. I've asked on IRC and can't get the hang of it, and I've searched for
appropriate commands to exhaustion. And I know there are thousands like me.
I am really trying to not turn off SELinux with this server, and only have this
one showstopper error. But I don't know what to do with this gibberish:
type=AVC msg=audit(1511826731.712:227): avc: denied { dac_override } for
pid=1615 comm="spamass-milter" capability=1
scontext=system_u:system_r:spamass_milter_t:s0
tcontext=system_u:system_r:spamass_milter_t:s0 tclass=capability permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow
this access.
Ch-yea, sure, I'll get right on that...
Re: spamd Will Not Create unix:socket
On 27 Nov 2017, at 22:45 (-0500), Colony.three wrote: Is anyone using the unix:socket for spamaassassin's milter? When I turned on SELinux, it will not let me change the group of the spamass-milter socket. (/run/spamass-milter/postfix/sock) /var/log/messages spamass-milter: group option, chown: Operation not permitted G**gle's baffled how to set SELinux to fix this. The policycoreutils-python package, in particular its audit2why and audit2allow tools, are indispensable for diagnosing and solving SELinux issues. A particular advantage they have over Google, Bing, or StackOverflow is that they are designed specifically to diagnose and solve SELinux problems and they work really fast... -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: spamd Will Not Create unix:socket
Is anyone using the unix:socket for spamaassassin's milter? When I turned on SELinux, it will not let me change the group of the spamass-milter socket. (/run/spamass-milter/postfix/sock) /var/log/messages spamass-milter: group option, chown: Operation not permitted G**gle's baffled how to set SELinux to fix this.
Re: spamd Will Not Create unix:socket
On 11/27/2017 11:53 AM, Colony.three wrote: >> It simply would not create /run/spamassassin directory on boot. It is >> supposed to create it automatically like clamd does, since /run is wiped >> at each boot. To make it work I finally had to add: >> ExecStartPre=/usr/bin/mkdir /run/spamassassin >> ExecStartPre=/bin/chown -R spamd:spamd /run/spamassassin > > There's a root exploit for the "spamd" user in that last line. Assuming > you got the tmpfiles.d thing working, you should delete those > ExecStartPre commands. Can you explain further please? If this is true, someone should tell Red Hat that their /usr/lib/systemd/system/spamass-milter-root.service has the same problem. I need spamass-milter-root to be able to write to the spamassassin socket so it can communicate with spamd. Recommendations requested. PS - I'm not using tmpfiles.d, I'm using systemd's RuntimeDirectory=spamassassin RuntimeDirectoryMode=770 ... to create the /run directory.
Re: spamd Will Not Create unix:socket
On 11/27/2017 11:53 AM, Colony.three wrote: > > It simply would not create /run/spamassassin directory on boot. It is > supposed to create it automatically like clamd does, since /run is wiped > at each boot. To make it work I finally had to add: > ExecStartPre=/usr/bin/mkdir /run/spamassassin > ExecStartPre=/bin/chown -R spamd:spamd /run/spamassassin > There's a root exploit for the "spamd" user in that last line. Assuming you got the tmpfiles.d thing working, you should delete those ExecStartPre commands.
Re: spamd Will Not Create unix:socket
On Mon, 27 Nov 2017, sha...@shanew.net wrote: I wonder if it's worth adding a note to the wiki, or even the --socketpath section of the spamd man-page? *That* would be something the SA team *could* do... I'd be happy to do the commit if someone could provide some text. On Mon, 27 Nov 2017, John Hardin wrote: On Mon, 27 Nov 2017, Colony.three wrote: > > I suspect you need an entry in /etc/tmpfiles.d so that directory gets > > created at boot time. > > Indeed there is no tmpfiles in the spamassassin package. (I've never > heard > of this in 22 years) How can this be, in the 21st Century? As I'd > suspected, everyone is settling for the tcp:port. > > What should I do about this, if anything? Fix it just for myself, or > let > someone else know? Report it to the RedHat bugzilla. The SA team doesn't handle distro-specific packaging issues. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The tree of freedom must be freshened from time to time with the blood of tyrants and tyrannosaurs. -- DW, commenting on the GM6 Lynx .50BMG bullpup --- 242 days since the first commercial re-flight of an orbital booster (SpaceX)
Re: spamd Will Not Create unix:socket
> sha...@shanew.net kirjoitti 27.11.2017 kello 20.32: > > or what it's worth, there's no > tmpfiles.d entry on my Ubuntu or Gentoo systems (Gentoo does its > thing in the init script). Debian (well, Raspbian for me) does have it. Apparently Ubuntu has removed it! signature.asc Description: Message signed with OpenPGP
Re: spamd Will Not Create unix:socket
tmpfiles.d became a thing when /run became a temporary filesystem, so it is relatively new. And most of the time packages install the necessary files in /usr/lib/tmpfiles.d, so admins may have never run up against this issue since it became a thing. As John says, you can file a bug report with RedHat. Technically that directory is only necessary when you're running spamd on a socket, so they may not consider it a bug. For what it's worth, there's no tmpfiles.d entry on my Ubuntu or Gentoo systems (Gentoo does its thing in the init script). I wonder if it's worth adding a note to the wiki, or even the --socketpath section of the spamd man-page? On Mon, 27 Nov 2017, John Hardin wrote: On Mon, 27 Nov 2017, Colony.three wrote: > I suspect you need an entry in /etc/tmpfiles.d so that directory gets > created at boot time. Indeed there is no tmpfiles in the spamassassin package. (I've never heard of this in 22 years) How can this be, in the 21st Century? As I'd suspected, everyone is settling for the tcp:port. What should I do about this, if anything? Fix it just for myself, or let someone else know? Report it to the RedHat bugzilla. The SA team doesn't handle distro-specific packaging issues. -- Public key #7BBC68D9 at| Shane Williams http://pgp.mit.edu/| System Admin - UT CompSci =--+--- All syllogisms contain three lines | sha...@shanew.net Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: spamd Will Not Create unix:socket
On Mon, 27 Nov 2017, Colony.three wrote: I suspect you need an entry in /etc/tmpfiles.d so that directory gets created at boot time. Indeed there is no tmpfiles in the spamassassin package. (I've never heard of this in 22 years) How can this be, in the 21st Century? As I'd suspected, everyone is settling for the tcp:port. What should I do about this, if anything? Fix it just for myself, or let someone else know? Report it to the RedHat bugzilla. The SA team doesn't handle distro-specific packaging issues. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- ...much of our country's counterterrorism security spending is not designed to protect us from the terrorists, but instead to protect our public officials from criticism when another attack occurs. -- Bruce Schneier --- 242 days since the first commercial re-flight of an orbital booster (SpaceX)
Re: spamd Will Not Create unix:socket
I suspect you need an entry in /etc/tmpfiles.d so that directory gets > created at boot time. > > Google tmpfiles.d or see this redhat blog page: > https://developers.redhat.com/blog/2016/09/20/managing-temporary-files-with-systemd-tmpfiles-on-rhel7/ Indeed there is no tmpfiles in the spamassassin package. (I've never heard of this in 22 years) How can this be, in the 21st Century? As I'd suspected, everyone is settling for the tcp:port. What should I do about this, if anything? Fix it just for myself, or let someone else know?
Re: spamd Will Not Create unix:socket
I suspect you need an entry in /etc/tmpfiles.d so that directory gets created at boot time. Google tmpfiles.d or see this redhat blog page: https://developers.redhat.com/blog/2016/09/20/managing-temporary-files-with-systemd-tmpfiles-on-rhel7/ On Mon, 27 Nov 2017, Colony.three wrote: I have fought with this for days, and finally had to hotwire it. But I'd like to understand what's going on. RHEL7 with spamassassin 3.4.0 and spamass-milter-postfix 0.4.0. /etc/sysconfig/spamassassin SPAMDOPTIONS="--daemonize --create-prefs --max-children=5 --username=spamd --groupname=spamd --socketpath=/run/spamassassin/spamd.sock --socketowner=spamd --socketgroup=spamd --socketmode=660 --ipv4-only" spamassassin.service: [Unit] Description=Spamassassin daemon After=syslog.target network.target PartOf=spamassassin-update.service [Service] Type=forking PIDFile=/run/spamd.pid EnvironmentFile=-/etc/sysconfig/spamassassin ExecStartPre=-/sbin/portrelease spamd ExecStart=/usr/bin/spamd --pidfile /run/spamd.pid $SPAMDOPTIONS StandardOutput=syslog StandardError=syslog Restart=always [Install] WantedBy=multi-user.target It simply would not create /run/spamassassin directory on boot. It is supposed to create it automatically like clamd does, since /run is wiped at each boot. To make it work I finally had to add: ExecStartPre=/usr/bin/mkdir /run/spamassassin ExecStartPre=/bin/chown -R spamd:spamd /run/spamassassin SELinux is set to Permissive, so that's not it. Any ideas? -- Public key #7BBC68D9 at| Shane Williams http://pgp.mit.edu/| System Admin - UT CompSci =--+--- All syllogisms contain three lines | sha...@shanew.net Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
spamd Will Not Create unix:socket
I have fought with this for days, and finally had to hotwire it. But I'd like to understand what's going on. RHEL7 with spamassassin 3.4.0 and spamass-milter-postfix 0.4.0. /etc/sysconfig/spamassassin SPAMDOPTIONS="--daemonize --create-prefs --max-children=5 --username=spamd --groupname=spamd --socketpath=/run/spamassassin/spamd.sock --socketowner=spamd --socketgroup=spamd --socketmode=660 --ipv4-only" spamassassin.service: [Unit] Description=Spamassassin daemon After=syslog.target network.target PartOf=spamassassin-update.service [Service] Type=forking PIDFile=/run/spamd.pid EnvironmentFile=-/etc/sysconfig/spamassassin ExecStartPre=-/sbin/portrelease spamd ExecStart=/usr/bin/spamd --pidfile /run/spamd.pid $SPAMDOPTIONS StandardOutput=syslog StandardError=syslog Restart=always [Install] WantedBy=multi-user.target It simply would not create /run/spamassassin directory on boot. It is supposed to create it automatically like clamd does, since /run is wiped at each boot. To make it work I finally had to add: ExecStartPre=/usr/bin/mkdir /run/spamassassin ExecStartPre=/bin/chown -R spamd:spamd /run/spamassassin SELinux is set to Permissive, so that's not it. Any ideas?
