MOAB #17 - slpd

[Landon Fuller]

With Personal File Sharing enabled, slpd is still not running. Is a
hidden button for turning this on?

-landonf

[MaxP]

On 18 Jan., 08:28, Landon Fuller <land...@bikemonkey.org> wrote:
> With Personal File Sharing enabled, slpd is still not running. Is a
> hidden button for turning this on?

10.4.8 BUILD 8L127 PowerPC
Sharing off:
dynam237:~$ ps -aux | grep slp
1007 2.3 0.2 27372 820 p1 S+ 8:58AM 0:00.01 grep slp

Sharing ON:
dynam237:~$ ps -aux | grep slp
root 1029 0.0 0.4 30932 2292 ?? Ss 8:58AM 0:00.03
slpd -f /e
1034 0.0 0.0 27808 4 p1 R+ 8:58AM 0:00.00
grep slp
HTH
MaxP

[MaxP]

I have SLP ticked on in Applications/Utilities/Directory Services.

Oh, btw it seems that slpd keeps running after sharing is turned off...
So one should "sudo killall slpd" afterwards
MaxP

[MaxP]

In a nutshell,

SLP ON in DirectoryServices before starting SHARING starts slpd.

SLP ON after starting SHARING does not start slpd.
SLP ON and SHARING OFF does not start slpd.
SLP OFF prevents slpd from starting.

Apologizes for needing three posts to clarify that. It's still too
early.
MaxP

[Finlay Dobbie]

On 18/01/07, MaxP <mper...@googlemail.com> wrote:
>
> In a nutshell,
>
> SLP ON in DirectoryServices before starting SHARING starts slpd.

Not here. SLP is on in Directory Services by default, sharing is off.
No slpd was running before turning Personal File Sharing on. It
continued running after personal file sharing was disabled.

-- Finlay

[dinornis]

10.4.8 (8L127) ppc
System Prefs -> Sharing -> Personal File Sharing
has been turned on, and always runs.
System Prefs -> Network -> Configure Interface -> Appletalk
is off by default, has never been turned on
Applications/Utilities/Directory\ Access -> Services
has the default with the following ON:
Appletalk, Bonjour, LDAPv3, SLP, SMB/CIFS

I see no signs that slpd is running.

Another Mac on the subnet running from the
natd nic in slot pci3 can connect afp.
Browse from the connection dialog shows
this machine, but this may be from cached info.

Question 2:
How does this affect OS-X Server?
Some of the binaries in their server versions are hardened,
some are not, and our whole point of running
a server is for file-sharing....

[MaxP]

On 18 Jan., 10:12, "Finlay Dobbie" <finlay.dob...@gmail.com> wrote:
>
> > SLP ON in DirectoryServices before starting SHARING starts slpd.
Not here. SLP is on in Directory Services by default, sharing is off.
> No slpd was running before turning Personal File Sharing on. It
> continued running after personal file sharing was disabled.

Then my description was misleading as I tried to say exactly the same
as you.
My Mac reacts exactly like your's.
MaxP

[das]

> Question 2:
> How does this affect OS-X Server?
> Some of the binaries in their server versions are hardened,
> some are not, and our whole point of running
> a server is for file-sharing....

slpd sits on port 427. You can therefore certainly firewall off port
427.

[VistaUser]

That takes care of the remote vector how about access to the local
socket though?
(eaemtxy02)

On Jan 18, 9:18 am, "das" <d...@doit.wisc.edu> wrote:
> > Question 2:
> > How does this affect OS-X Server?
> > Some of the binaries in their server versions are hardened,
> > some are not, and our whole point of running

> > a server is for file-sharing....slpd sits on port 427. You can therefore certainly firewall off port
> 427.

[das]

On Jan 18, 11:11 am, "VistaUser" <eaemtx...@sneakemail.com> wrote:
> That takes care of the remote vector how about access to the local
> socket though?
> (eaemtxy02)

Well, if you're worried about a *local* user exploiting this (meaning
they'd have to have shell access to the machine), the workaround is to
not have slpd running (see below). slpd isn't required for file sharing
to work. I believe the person I was responding to was asking how this
could be mitigated remotely on Mac OS X Server machines running slpd
alongside AppleShare services.

The workaround, on either Mac OS X or Mac OS X Server, isn't to disable
file sharing services...it's to disable (uncheck) the SLP service in
/Applications/Utilities/Directory Access.app.

[Landon Fuller]

Not a rhetorical question -- does anyone still use SLP?

In terms of patching non-user processes, I've attached an old project
in which I experimented with attaching to mDNSResponder using
mach_star. There's a simple tool that finds the process by name and
loads a bundle. I was experimenting with 1) setuid/setgid'ing &
chrooting mDNSResponder, and 2) Tweaking mDNSResponder to use
routable multicast; bear in mind the project is unfinished and rough
around the edges.

It should be possible to get this working on Intel macs via:
http://guiheneuf.org/mach%20inject%20for%20intel.html

I'm not sure what the best way is to attach and inject code into a
process when it is first started (this code just finds a running
process). Any thoughts?

-landonf

[frozenINcarbonite]

So how do I know if I have slpd on? And if I do, how do I turn it off
(in easy to understand form :-) )?

> PGP.sig
> 1KDownload

[dinornis]

On Jan 19, 6:34 am, "das" <d...@doit.wisc.edu> wrote:
>
> The workaround, on either Mac OS X or Mac OS X Server, isn't to disable
> file sharing services...it's to disable (uncheck) the SLP service in
> /Applications/Utilities/Directory Access.app.

Yes, I understand that. To elaborate my point,
altho' slp is "ticked ON" in Directory Access.app for both
desktop and server, it appears not to run for 10.4 desktop,
but I know it is running on 10.4 server. Differences in config?
Yes, my server authenticates users to remote LDAP,
and I have smb explicity activated.

But I know some of the binaries are different, and I know
some of the server source is not published, hence I asked
does this break the Server? I have only a production system here
which I'd rather not use as a guinea pig...

[dinornis]

On Jan 19, 6:58 am, Landon Fuller <land...@bikemonkey.org> wrote:
> Not a rhetorical question -- does anyone still use SLP?
>

Sorry for a rhetorical reply - is slp needed by Windows clients
to "Search Network Neighborhood"?
is slp one of those "sleeping" daemons, activated by xinetd
only when an incoming request is detected?
Again,sorry for a silly question, but if you upgrade
10.2 -> 10.3 -> 10.4 there will exist 2 folders
/etc/xinetd.d & /etc/xinetd.d-migrated2launchd
and there are empty files named for the processes
xinetd is supposed to monitor. Unfortunately both
Macs within my reach have had virgin 10.4 installs,
and those 2 folders are empty. Anybody got slpd in there?

Correction to my above post:
slpd is -not- freerunning on 10.4.8 Server, with afp, smb, ftp
But I know I did see it while chasing pids some time
prior to 10.4.6. Maybe Apple has "fixed" this ...

[Landon Fuller]

On Jan 18, 2007, at 09:58, Landon Fuller wrote:

I'm not sure what the best way is to attach and inject code into a process when it is first started (this code just finds a running process). Any thoughts?

Here's what I'm thinking; thanks to nemo for the SIGTRAP idea.

The patch daemon finds launchd:

- Patch execve() to call ptrace(PT_TRACE_ME, ...)

- Patch fork() to wait4(), watching for WIFSTOPPED and WIFEXITED -- alternatively, set up a SIGTRAP handler and look at siginfo->si_pid

- When SIGTRAP is detected, patch the subprocess, call PT_DETACH.

wait4() may not cut it, since you can obviously call fork without an exec, and we don't want to sit around waiting for a SIGTRAP that will never come.

This also breaks suid() execution, and patching launchd, at boot, automatically, could break everything. Safety belts?

So very hackish.

-landonf

[Landon Fuller]

At some point, I wonder if an on-disk patch isn't the cleaner solution.

-landonf

[Landon Fuller]

On Jan 18, 2007, at 18:09, Landon Fuller wrote:

Here's what I'm thinking; thanks to nemo for the SIGTRAP idea.

The patch daemon finds launchd:

- Patch execve() to call ptrace(PT_TRACE_ME, ...)

- Patch fork() to wait4(), watching for WIFSTOPPED and WIFEXITED -- alternatively, set up a SIGTRAP handler and look at siginfo->si_pid

- When SIGTRAP is detected, patch the subprocess, call PT_DETACH.

wait4() may not cut it, since you can obviously call fork without an exec, and we don't want to sit around waiting for a SIGTRAP that will never come.

This also breaks suid() execution, and patching launchd, at boot, automatically, could break everything. Safety belts?

So very hackish.

I've got a simple a daemon (fixd) implementation that uses mach_inject to create a thread in slpd through a sleep/poll cycle. I've been mulling the above solution over, and it's pretty darn evil. Better alternative:

kevent, EVFILT_PROC, NOTE_FORK

Unfortunately this relies on polling for processes with a ppid that matches the kevent -- NOTE_TRACK would solve this, but 10.4 kernel panics when using NOTE_TRACK (including 10.4.8):

http://lists.apple.com/archives/Darwin-kernel/2005/Jul/msg00115.html

-landonf

[dinornis]

With all due respect to the programming skills evident here,
do we need to 'fix" slpd if it is not needed?

I have proved to my satisfaction that slpd does -not- run
unfettered on machines which have had a virgin install
of 10.4. It does run on Macs that have been updated
from 10.3.5 or earlier.

What I do not know is where or how to look to see if it
is run momentarily in response to incoming requests.

What I have done on a test machine is

sudo mv /usr/sbin/slpd /usr/sbin/slpdAppleBorked

Nothing has broken in my dailly life, ymmv

d

[Landon Fuller]

On Jan 19, 2007, at 11:36, dinornis wrote:

>
>
>
> With all due respect to the programming skills evident here,
> do we need to 'fix" slpd if it is not needed?

I think your reasoning is spot on, and I don't think we do -- I'm
more concerned about solving the "how to patch daemons" issue in case
a more critical issue is made evident.

-landonf

[William A. Carrel]

We'd then need to wait for the execve() or NOTE_EXEC on the child,
right? It feels like there might be a race for doing NOTE_EXEC and the
execve executing and no real way to tell which side of that we're
running on. Not much use in patching before the exec call.

ptrace has the advantage of halting execution in the child (before it
even starts) while we're wandering in to tweak bits. With kevent
everything is still running and we may have to make sure that affected
code is already loaded but isn't being currently executed when we
decide to wander in and change things. That seems like a lot more work
and doesn't feel any cleaner.

--
wac

[Landon Fuller]

Ah, sorry, you're right. We'd need to wait for NOTE_EXEC, which means
there is another race -- get the FORK event, register for the EXEC
event, miss the exec event

> ptrace has the advantage of halting execution in the child (before it
> even starts) while we're wandering in to tweak bits. With kevent
> everything is still running and we may have to make sure that affected
> code is already loaded but isn't being currently executed when we
> decide to wander in and change things. That seems like a lot more work
> and doesn't feel any cleaner.

Yeah -- there is a race condition in using kevent. APE /
mach_override atomically patch the functions, but there's still a
window in which the code is not patched.
Maybe ptrace() is the more reliable solution.

-landonf