Hallo to everyone! I am trying to harden solaris 10 x86 an I read a
recommendation (from CIS) to lock system accounts (bin, nuucp, smmsp,
listen, gdm, webservd, nobody, noaccess, nobody4).
Why should i do that?
Isn't it risky for the proper operation of my system, to lock these
accounts?  

Thanks in advance
bill

In article <1162699803.478132.93690@h48g2000cwc.googlegroups.com>,
 "billyyo" <giotsas@gmail.com> wrote:

> Hallo to everyone! I am trying to harden solaris 10 x86 an I read a
> recommendation (from CIS) to lock system accounts (bin, nuucp, smmsp,
> listen, gdm, webservd, nobody, noaccess, nobody4).
> Why should i do that?
> Isn't it risky for the proper operation of my system, to lock these
> accounts?  
> 
> Thanks in advance
> bill

Read up on the difference between disabled accounts and locked accounts.  
One won't allow you to do cron jobs, which will break accounting and sar.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...

Michael Vilain <vilain@spamcop.net> wrote:
> In article <1162699803.478132.93690@h48g2000cwc.googlegroups.com>,
> "billyyo" <giotsas@gmail.com> wrote:
> 
>> Hallo to everyone! I am trying to harden solaris 10 x86 an I read a
>> recommendation (from CIS) to lock system accounts (bin, nuucp, smmsp,
>> listen, gdm, webservd, nobody, noaccess, nobody4).
>> Why should i do that?
>> Isn't it risky for the proper operation of my system, to lock these
>> accounts?  
>> 
>> Thanks in advance
>> bill
> 
> Read up on the difference between disabled accounts and locked accounts.  
> One won't allow you to do cron jobs, which will break accounting and sar.

If you have a look at /etc/shadow you will find that most of the system
accounts already have locked or invalid passwords.

-- 
Geoff Lane, Airstrip One

Thank you for your replies!

> Read up on the difference between disabled accounts and locked accounts.
> One won't allow you to do cron jobs, which will break accounting and sar.

I' ve read in this site:
http://www.securitydocs.com/library/2636
that a locked account on the other hand is one that is not permitted to
access the system in any way - it is locked. A locked account differs
from one marked as non-login in that locked accounts are not permitted
to use delayed execution methods like cron(1M).

So if I lock an account then isn't it like disabling an account?

> If you have a look at /etc/shadow you will find that most of the system
> accounts already have locked or invalid passwords.

The systems accounts by default are non-login accounts. But non-login
accounts can execute methods like cron. The recommendation from CIS
says that i should lock them. But i use Apache 2 so I'm afraid that
locking webservd account will cause apache 2 to collapse.

billyyo wrote:

> Hallo to everyone! I am trying to harden solaris 10 x86 an I read a
> recommendation (from CIS) to lock system accounts (bin, nuucp, smmsp,
> listen, gdm, webservd, nobody, noaccess, nobody4).
> Why should i do that?
> Isn't it risky for the proper operation of my system, to lock these
> accounts?  
> 
> Thanks in advance
> bill
> 

Locking the accounts simply prevents anyone from logging in as bin, 
nuucp, smmsp, etc.  It does not prevent the accounts from owning various 
resources nor does it prevent root from doing, in effect, "su bin".

Richard B. Gilbert wrote:
> Locking the accounts simply prevents anyone from logging in as bin,
> nuucp, smmsp, etc.  It does not prevent the accounts from owning various
> resources nor does it prevent root from doing, in effect, "su bin".

Thanks! I checked your reply and you are right. But the recommended
configuration is to set an invalid shell (for example /dev/null) for
these accounts (except from sys and daemon). Isn't it bad for their
operation. I hope my question isn't stupid :-)

In <1162740611.686606.214560@b28g2000cwb.googlegroups.com> "billyyo" <giotsas@gmail.com> writes:

>Richard B. Gilbert wrote:
>> Locking the accounts simply prevents anyone from logging in as bin,
>> nuucp, smmsp, etc.  It does not prevent the accounts from owning various
>> resources nor does it prevent root from doing, in effect, "su bin".

>Thanks! I checked your reply and you are right. But the recommended
>configuration is to set an invalid shell (for example /dev/null) for
>these accounts (except from sys and daemon). Isn't it bad for their
>operation. I hope my question isn't stupid :-)

That would prevent root from doing `su bin', but of course root could
just change the shell and then do it.  I don't see much benefit to
giving locked accounts an invalid shell.

-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-

billyyo wrote:

> Richard B. Gilbert wrote:
> 
>>Locking the accounts simply prevents anyone from logging in as bin,
>>nuucp, smmsp, etc.  It does not prevent the accounts from owning various
>>resources nor does it prevent root from doing, in effect, "su bin".
> 
> 
> Thanks! I checked your reply and you are right. But the recommended
> configuration is to set an invalid shell (for example /dev/null) for
> these accounts (except from sys and daemon). Isn't it bad for their
> operation. I hope my question isn't stupid :-)
> 

I suspect that these accounts never actually execute a shell.  I just 
looked at one of my Solaris systems and found that all the executing 
processes were owned by either root or my personal account!  This does 
not prove that nothing ever executes as "bin" but I suspect that these 
accounts seldom, if ever, execute any shells or anything else.

Thanks both for your answers!

Gary Mills wrote:

> That would prevent root from doing `su bin', but of course root could
> just change the shell and then do it.  I don't see much benefit to
> giving locked accounts an invalid shell.

The CIS Solaris 10 Benchmark says "... shell field in the password file
should contain an invalid shell. /dev/null is a good choice because it
is not a valid
login shell, and should an attacker attempt to replace it with a copy
of a valid shell the
system will not operate properly."

I understand it this way:
Normally the shell field for systems accounts, in the passwd file, is
empty. An attacker may try to add his shell in the end of each line of
passwd file, using a script. If I add /dev/null (or something invalid)
in this field then the execution of such a script will give something
like /dev/null/bin/sh which is also invalid, so no problem!

Richard B. Gilbert wrote:

> I suspect that these accounts never actually execute a shell.  I just
> looked at one of my Solaris systems and found that all the executing
> processes were owned by either root or my personal account!  This does
> not prove that nothing ever executes as "bin" but I suspect that these
> accounts seldom, if ever, execute any shells or anything else.

Thank you for your time. Your answer is very clear! My question solved.

"billyyo" <giotsas@gmail.com> writes:

>The CIS Solaris 10 Benchmark says "... shell field in the password file
>should contain an invalid shell. /dev/null is a good choice because it
>is not a valid
>login shell, and should an attacker attempt to replace it with a copy
>of a valid shell the system will not operate properly."

I can't really make much sense of the last bit; should the attacker
replace *what* with a valid shell?  (And why would they bother
replacing a file with a shell if they could just alter the
password)

>I understand it this way:
>Normally the shell field for systems accounts, in the passwd file, is
>empty. An attacker may try to add his shell in the end of each line of
>passwd file, using a script. If I add /dev/null (or something invalid)
>in this field then the execution of such a script will give something
>like /dev/null/bin/sh which is also invalid, so no problem!

No; because if they could append a shell to the field they could just
as well replace it.

The accounts which are marked "nologin" accounts cannot be logged into;
they can still be used as a target for su by root.

There is no reason to change the shell (for one, it makes certain
system administrative actions impossible and there's no way the users
can be logged into)



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.

Casper H.S. Dik wrote:
> I can't really make much sense of the last bit; should the attacker
> replace *what* with a valid shell?  (And why would they bother
> replacing a file with a shell if they could just alter the
> password)

The full text of CIS recommendation (http://www.cisecurity.org) is the
following:
"Accounts that are not being used by regular users should be locked.
Not only should
the password field for the account be set to an invalid string (which
is the default
setting for these accounts under Solaris), but also the shell field in
the password file
should contain an invalid shell. /dev/null is a good choice because it
is not a valid
login shell, and should an attacker attempt to replace it with a copy
of a valid shell the
system will not operate properly."

I also don't understand it clearly.My previous explanation was an
attempt to make sense.  I guess you are right.

On 2006-11-06 13:01:54 +0000, "billyyo" <giotsas@gmail.com> said:

> 
> Casper H.S. Dik wrote:
>> I can't really make much sense of the last bit; should the attacker
>> replace *what* with a valid shell?  (And why would they bother
>> replacing a file with a shell if they could just alter the
>> password)
> 
> The full text of CIS recommendation (http://www.cisecurity.org) is the
> following:
> "Accounts that are not being used by regular users should be locked.
> Not only should
> the password field for the account be set to an invalid string (which
> is the default
> setting for these accounts under Solaris), but also the shell field in
> the password file
> should contain an invalid shell. /dev/null is a good choice because it
> is not a valid
> login shell, and should an attacker attempt to replace it with a copy
> of a valid shell the
> system will not operate properly."
> 
> I also don't understand it clearly.My previous explanation was an
> attempt to make sense.  I guess you are right.

It reads like they're expecting someone to turn /dev/null into an 
executable shell. That would pretty much break the system, I'd think.

Cheers,

Chris

Chris Ridd <chrisridd@mac.com> wrote:

> It reads like they're expecting someone to turn /dev/null into an 
> executable shell. That would pretty much break the system, I'd think.

I read that to be the point.

If the shell were some other object (say /etc/no_such_shell), then some
exploit that allowed a real shell to replace it might go unnoticed.  An
exploit that let someone replace /dev/null with a shell would
(hopefully) be detected more rapidly.  :-)

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >