[ale] Service account allows sudo but no login

[JD]

Nice points Michael.  If people really want to have fun - run an NFS server and
mix up the UIDs between client multiple clients and server. ;)  Watch the fun!

In the old days, before sudo, we'd create multiple accounts with different
names, but the same uid. This way, different users could access and control the
application account, but we'd get a log of the su - appaccount to have some idea
who did what, when.  I still create a secondary root account on most systems
with this method - shove a huge, complex, password into it, store that password
in KeePassX and forget it.  Once in a while ... not very often, that extra root
account has saved me.  Not so much on Linux (we can all mount a partition and
reset a password with a flash ISO), but on UNIX.

Sudo is much better in many, many, many ways.  Everything I reread the sudo man
page, I learn something knew.

On 07/31/2013 09:23 AM, Michael Trausch wrote:
> So a little more on this at a lower level, in the event that anyone is
> interested. I had a hard time wrapping my head around the concept originally and
> I can't imagine that I am alone there. 
> 
> User accounts and their ID numbers are nothing more than an agreement between
> user space and kernel space. For example, it is possible to hand UID numbers out
> and attach them to files and other objects, even when the user doesn't exist. A
> program running as root need not authenticate a user---or may authenticate a
> user by some means other than the system default---before handing a process that
> credential to be its very own. 
> 
> With the UID space being 32-bits wide now, it can be used for things such as
> assigning identifiers in a cryptographic manner that can be verified by another
> system (and allow for uids to be tied together at a higher level).
> 
> The most important part is that to the kernel, it is just a number. Nothing
> more. It is nothing special. And for that matter, this is how it is on virtually
> all multiuser systems. The UID is something that is created and provisioned by a
> user space application, but managed and checked by the kernel. 
> 
> Sent from my iPhone
> 
> On Jul 30, 2013, at 1:30 PM, Jim Kinney <jim.kinney at gmail.com
> <mailto:jim.kinney at gmail.com>> wrote:
> 
>> set account to be "disabled" by having password field in /etc/shadow to '!!'.
>> The shell can be what ever is needed to start service. If the service needs no
>> shell, set it to /sbin/nologin.
>>
>> eg.:
>>
>> # grep postgres /etc/passwd
>> postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
>> # grep postgres /etc/shadow
>> postgres:!!:15824::::::
>>
>>
>> No user named postgres can login BUT (only) root _can_ su - postgres since
>> there is a shell.
>>
>> These accounts can't be su'ed to :
>> # grep nologin /etc/passwd
>> bin:x:1:1:bin:/bin:/sbin/nologin
>> daemon:x:2:2:daemon:/sbin:/sbin/nologin
>> adm:x:3:4:adm:/var/adm:/sbin/nologin
>> lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
>>
>> # su - bin
>> This account is currently not available.
>> # su - lp
>> This account is currently not available.
>>
>>
>>
>>
>> On Tue, Jul 30, 2013 at 12:28 PM, leam hall <leamhall at gmail.com
>> <mailto:leamhall at gmail.com>> wrote:
>>
>>     Is there a good security practice for service accounts? The goal is that
>>     an app can run as "myapp" but no one can login as myapp and myapp's
>>     password does not expire.
>>
>>     So far best practice seems to be having a regular shell and no password,
>>     with specific people/groups allowed to sudo over.
>>
>>     Thoughts?
>>
>>     Leam
>>