[ale] Service account allows sudo but no login

[Michael Trausch]

Well, kind of.

Keeping in mind that UIDs and GIDs are just integers as far as the kernel is concerned, and any super privileged process is (SELinux aside) allowed to spawn a process and switch to an arbitrary UID, yes, it is possible to block transitions with PAM, with caveats. 

To truly use PAM securely requires that you not be using any database that requires root or super user privilege to access, such as the shadow file. (Of course this also means that normal applications cannot authenticate users in a normal PAM configuration, which stinks.)

BSD authentication provides a nicer solution in that a daemon runs to handle authentications and applications then ask the daemon to do the dirty work for it. This also enforces a network boundary (as sockets are used) and a process boundary (as code that runs as the superuser is no longer required to be linked into the process).

Of course, it is possible to do that with PAM, if one wanted to. All that is required is a runs-as-root authentication helper that can read shadow and communicate using unix domain sockets with the user process. This works because credentials are allowed to be passed over unix sockets whereas they cannot be over INET ones. This is in part how SSSD works. 

SELinux is still useful to protect against kernel vulnerabilities in such a scenario, and can be used to effectively delegate policy to whatever the login helper is in order to enforce complex policies. 

This also happens to be, I think, why network authentication is so much easier than local authentication; it requires no local superuser privilege, and provides a security boundary at every networked system. 

Sent from my iPhone

On Aug 5, 2013, at 11:47 AM, Jim Kinney <jim.kinney at gmail.com> wrote:

> As root, su -s will provide a shell. As wheel group member with sudo, same results. As non-root user, no.
> 
> Seems like there should be a way to close off those with Pam but I've not thought about it before now. SeLinux will block su transitions easily.
> 
> On Aug 5, 2013 11:15 AM, "Derek Atkins" <warlord at mit.edu> wrote:
>> Jim Kinney <jim.kinney at gmail.com> writes:
>> 
>> > 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.
>> 
>> You could still su to these accounts by providing su a shell:
>> 
>>   su -s /bin/bash - bin
>> 
>> -derek
>> 
>> --
>>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>>        Member, MIT Student Information Processing Board  (SIPB)
>>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>>        warlord at MIT.EDU                        PGP key available
>> _______________________________________________
>> 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
> _______________________________________________
> 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/20130805/b75738d6/attachment.html>