Rusty Wright <rusty@socrates.Berkeley.EDU> writes:

>You may also want to turn off the starting of various services by the
>scripts in the /etc/rc*.d directories. I rename the scripts by
>appending zz_ to them to disable them. Here's my list of zz'd files:

># ls rc*.d/zz_*
>rc2.d/zz_S71rpc* rc2.d/zz_S90wbem* rc3.d/zz_S81volmgt*
>rc2.d/zz_S72slpd* rc2.d/zz_S99dtlogin* rc3.d/zz_S84appserv*
>rc2.d/zz_S73nfs.client* rc3.d/zz_S15nfs.server* rc3.d/zz_S90samba*
>rc2.d/zz_S74autofs* rc3.d/zz_S34dhcp* rcS.d/zz_S50devfsadm*
>rc2.d/zz_S74xntpd* rc3.d/zz_S50apache* rcS.d/zz_S95picld*
>rc2.d/zz_S76nscd* rc3.d/zz_S76snmpdx*
>rc2.d/zz_S85power* rc3.d/zz_S77dmi*

You should not/need not stop:

nscd -> kills some performance and may unmask bugs;
makes it impossible to edit /etc/resolv.conf
or nsswitch.conf after booting and have
the changes take effect.

picld -> is required for proper functioning of some hardware
you don't want to sit next to a Sun Blade x000
without picld running. Fortunately, the hardware
will send the fans runnign at full speed when it dies.

devfsadm -> is a required service; your pty allocation,
device configuration, usb hotplug and others will
not work without it. Your system may fail
in unexpected ways.

nfs.server -> isn't started when you don't share anything

Casper

Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
>Rusty Wright <rusty@socrates.Berkeley.EDU> writes:
>
>>You may also want to turn off the starting of various services by the
>>scripts in the /etc/rc*.d directories. I rename the scripts by
>>appending zz_ to them to disable them. Here's my list of zz'd files:
>

[8 lines snipped]

>
>You should not/need not stop:
>

[16 lines snipped]


BTW, and this is a generalisation, but I won't run any service for
which there is no man page, and some of those (devfsadm springs
to mind) didn't have one when they first appeared. I want to
know what those suckers are...

(I know devfsadm has a man page now, and others may have. I'm several
versions behind here at home.)


--
"The road to Paradise is through Intercourse."
[email me at huge [at] huge [dot] org [dot] uk]

huge@ukmisc.org.uk (Huge) writes:

>BTW, and this is a generalisation, but I won't run any service for
>which there is no man page, and some of those (devfsadm springs
>to mind) didn't have one when they first appeared. I want to
>know what those suckers are...

>(I know devfsadm has a man page now, and others may have. I'm several
>versions behind here at home.)

devfsadmd first appeared in a S7 patch; the manual page appeared in
a seperate patch. (106541-08/108068-01) As far as I can
reconstruct they came out at about the same time.

Casper

In article <415e75e2$0$14941$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:

> "Fred J. Bourgeois, III" <fjb3@sbcglobal.net> writes:
>
> >Same comment applies to the RPC services - do you really need walld?
> >I don't remember rpc.smserverd (is that the Sun admin tool?) but I
> >always disable it on my sparcs.
>
> rpc.smserverd is required for vold to work; the service is
> defined as follows:
>
> 100155/1 tli rpc/ticotsord wait root /usr/lib/smedia/rpc.smserverd
> rpc.smserverd
>
> Pay special attention to the 3rd field: "rpc/ticotsord" means
> that all it supports are connections over the TLI loopback
> device "ticotsord". It cannot be called remotely so it does not
> pose any kind of remote security risk.

But it does require that rpcbind be running to function. I don't like
the idea of having to start rpcbind in order to manage removable media
for a service that isn't called remotely. Any thoughts as to why it was
designed this way?

Josh

Josh McKee <jtmckee@rmac.know-spam-bogus.net> writes:

>But it does require that rpcbind be running to function. I don't like
>the idea of having to start rpcbind in order to manage removable media
>for a service that isn't called remotely. Any thoughts as to why it was
>designed this way?

Nope; not sure why running rpcbind is considered such a big
problem. (It is indeed listening on the network but always
on fixed port)

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

On Sat, 02 Oct 2004 16:46:45 +0000, Casper H. S. Dik wrote:

> Josh McKee <jtmckee@rmac.know-spam-bogus.net> writes:
>
>>But it does require that rpcbind be running to function. I don't like
>>the idea of having to start rpcbind in order to manage removable media
>>for a service that isn't called remotely. Any thoughts as to why it was
>>designed this way?
>
> Nope; not sure why running rpcbind is considered such a big
> problem. (It is indeed listening on the network but always
> on fixed port)

Thanks Casper. It does against good security practices of running the
least number of services possible. I don't understand why a network
service needs to be running in order to use removable media. Especially
if the automounter isn't listening on the network. It didn't use to be
this way. I'd be interested in knowing why it changed to this behavior.

Josh

In comp.security.unix Roy Nielsen <rsn@lanl.gov> wrote:
> In my group we've tried to tighten up security on our Solaris systems...

Can I suggest JASS? http://wwws.sun.com/software/security/jass/

It'll automate a lot of what you want to do manually. Just read the docs
- gives you a lot of control. If it's going to break something, disable
that script and secure it by hand.

PD

--
Paul Day Web: www.bur.st/~paul GPG Key ID: 7FF655A8

Thanks for the explanation on some of these. I've interspersed my
remarks/feedback after yours.

Casper H.S. Dik <Casper.Dik@Sun.COM> writes:

> You should not/need not stop:
>
> nscd -> kills some performance and may unmask bugs;
> makes it impossible to edit /etc/resolv.conf
> or nsswitch.conf after booting and have
> the changes take effect.

I never edit those files again after setting up a machine. I'm
curious to know what the performance hit is due to. So far I haven't
had any problems with it off for several months now.

>
> picld -> is required for proper functioning of some hardware
> you don't want to sit next to a Sun Blade x000
> without picld running. Fortunately, the hardware
> will send the fans runnign at full speed when it dies.

All of my machines are dinky little things; a desktop 150, and some
v100s and v150s. I haven't had any problems with this off for several
months now.

>
> devfsadm -> is a required service; your pty allocation,
> device configuration, usb hotplug and others will
> not work without it. Your system may fail
> in unexpected ways.
>

I'm able to login with ssh and start xterms ok with this turned off.
I don't use usb, or at least I don't do any hotplugging. As with the
others, it's been off for several months with no problems.

Here's what the output of ps -ef looks like on my system after
disabling all of the (unnecesasry for me) crud that Solaris normally
starts. qmgr, pickup, and master are the postfix MTA; I replace
sendmail with postfix since it's supposed to be more robust and have
fewer security issues (and it's a very simple drop-in replacement).

UID PID PPID C STIME TTY TIME CMD
root 0 0 0 03:06:52 ? 0:27 sched
root 1 0 0 03:06:53 ? 0:00 /etc/init -
root 2 0 0 03:06:53 ? 0:00 pageout
root 3 0 0 03:06:53 ? 1:41 fsflush
root 288 1 0 03:11:09 console 0:00 /usr/lib/saf/ttymon -g -h -p grunt.berkeley.edu console login: -T sun -d /dev/
root 160 1 0 03:10:57 ? 0:00 /usr/lib/utmpd
root 125 1 0 03:10:55 ? 0:00 /usr/sbin/inetd -s -t
root 136 1 0 03:10:56 ? 0:00 /usr/sbin/syslogd
root 146 1 0 03:10:56 ? 0:00 /usr/sbin/cron
root 269 1 0 03:10:59 ? 0:00 /usr/local/libexec/postfix/master
root 290 1 0 03:11:10 ? 0:00 /usr/lib/ssh/sshd
postfix 279 269 0 03:11:00 ? 0:00 qmgr -l -t fifo -u
postfix 655 269 0 19:49:10 ? 0:00 pickup -l -t fifo -u

Rusty Wright <rusty@socrates.Berkeley.EDU> writes:

>> devfsadm -> is a required service; your pty allocation,
>> device configuration, usb hotplug and others will
>> not work without it. Your system may fail
>> in unexpected ways.
>>

>I'm able to login with ssh and start xterms ok with this turned off.
>I don't use usb, or at least I don't do any hotplugging. As with the
>others, it's been off for several months with no problems.

It will fail at 32 ptys, I believe; that is the default number
of ptys created.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Fred J. Bourgeois, III wrote:

> I wrote a little C utility to disable lots of stuff on Solaris boxes,
> but I haven't touched it in years - I only ported it to Solaris 7 and 8
> (and maybe 6 also). If anyone is interested in a copy, let me know.
> It isn't very "smart" and I only used it a few times to setup freshly
> installed machines with most of the big security holes plugged.

You could use cfengine instead; aside from being available for Solaris,
it also works on Linux, HP-UX, and others.

http://www.cfengine.org

It allows you to manage your configurations, such that they become
resistant to change, can change for all systems centrally, and allows
automatic full system configure after install.

Combine it with JumpStart and how can you lose?