Re: [gentoo-security] Prevent users to login directly

[Michael Ihde]

Instead of all the "sudo su ...." stuff does this make things simpler.

Add the following lines to /etc/sudoers (assuming you also have the 
emerge user)

User_Alais EMERGE_ADMINS = user1, user2, user3
Host_Alais EMERGEABLE_HOSTS = host1, host2
Cmnd_Alias EMERGE = /usr/bin/emerge

EMERGE_ADMINS EMERGEABLE_HOSTS = (emerge) EMERGE

Are there any security problems with this?  If you wanted you could add 
stuff to the Cmnd_Alias to restrict users from being able to unmerge 
packages... I think that would be like this...

Cmnd_Alias EMERGE = /usr/bin/emerge, !/usr/bin/emerge *unmerge*, 
!/usr/bin/emerge *-C*

~Michael

Bart Alewijnse wrote:
>>Bart Alewijnse wrote:
>>| Errm. I was referring to the *user* 'emerge' - I wasn't aware you can
>>| use su to execute binaries. sudo, yes, but su? 'sudo su emerge' would
>>| cause sudo to run su with the command line parameter 'emerge' which
>>| can only be a username - rather than hand sudo two executable names,
>>| right?
>>| But if you're paranoid, you could likely require the path to emerge in
>>| sudoers, so that it'd have to be
>>| 'sudo su /usr/bin/emerge' - or possibly just that it'd only accept
>>| running emerge if the actual emerge binary being suggested for running
>>| is the one in /usr/bin. Since you don't have direct accidental access
>>| to that as either considered user, it's not a risk.
>>|
>>Yes, su can run commands with the -c option.  So 'su root -c "rm -rf /"'
>>would blow away your system.  However, in your example you don't have
>
>
> Good point, didn't know that.
>
> But root? What? I was suggesting only su-ing from selected users to
> the 'emerge' user.
>
> The worst you could do then is probably 'sudo su emerge -c
> /evil/emergee', which would then be executed as emerge - which I was
> assuming to be a non-admin account, just as a syntactic command line
> sugar inbetween step.
>
> The point to that was that people that would emerge would both have a
> common account (possibly good for config files), but just to the
> point, that that's a nice conceptual location you could run the actual
> emerge binary from - again, through sudo, because if emerge is an
> admin acccount, it might as well be root itself.
>
>
> Actually, indeed, just adjusting sudoers to have specific people have
> the ability to run /usr/bin/emerge would be enough, pretty much
> period.
>
>
> And if not that, according to taste and as someone just mailed me, you
> also do what I suggest in one step, indeed with a 'sudu so -c
> /usr/bin/emerge' with assorted
> things-you-actually-also-need-in-reality(tm) (again, I've not used
> sudo much at all)
>
> That's indeed simpler systemwise. I was just going for the
> understandable-for-people-not-on-this-list (and possibly myself next
> week) angle. Rather pointless, really. There are such things as
> scripts:)
>
>
> Interesing suggestion, but how exactly would you break out of chroot
> once you're properly authenticated? I mean, there's very little point
> to running emerge within a chrooted environment, right? You're doing
> something cleaner, though, so do please explain.
>
>
> But as I keep saying, security is entirely moot in this matter, as bad
> intentsions are met with essential root access no matter what you do,
> because emerge itself needs it. It's better than giving them root
> access as accidental typo's could be entirely fatal there, but not as
> the emerge user - unless you did something stupid with emerge, but
> then you shouldn't be emerging in the first place.
>
> --Bart Alewijnse
>
> --
> gentoo-security@g.o mailing list
>


--
gentoo-security@g.o mailing list