[ale] Service account allows sudo but no login

[Michael Trausch]

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> 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> 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
>> 
>> -- 
>> Mind on a Mission
>> 
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
> 
> 
> 
> -- 
> -- 
> James P. Kinney III
> 
> Every time you stop a school, you will have to build a jail. What you gain at one end you lose at the other. It's like feeding a dog on his own tail. It won't fatten the dog.
> - Speech 11/23/1900 Mark Twain
> 
> http://electjimkinney.org
> http://heretothereideas.blogspot.com/
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130731/54ff589d/attachment.html>