View Single Post

  #6 (permalink)  
Old 12-28-2005
Michael Heiming
 
Posts: n/a
Default Re: Question about SELinux and root privs

In comp.os.linux.security Menno Duursma <menno@desktop.lan>:
> On Wed, 28 Dec 2005 21:08:02 +0100, Michael Heiming wrote:
>> In comp.os.linux.security Menno Duursma <menno@desktop.lan>:
>>> On Wed, 28 Dec 2005 10:37:35 -0500, Pat Farrell wrote:
>>>> binary-nomad@hotmail.com wrote:
>>>>> I have a simple question - how do I make sure that if someone gets
>>>>> into my machine as root, on a Fedora 4 machine with SELinux enabled,
>>>>> they can't do any damage?
>>>>
>>>> You can't.
>>>> If you are logged in as root, you own the machine.

>>
>>> Well the "root" username is just that, hence:

>>
>>> usermod -l admin root
>>> useradd -g users root

>>
>> Presuming remote root access is already disabled,


> If you mean the "PermitRootLogin no" directive in sshd_config , that
> disallows UID 0 access which got mapped to the "admin" name in above
> example. "root" is just a normal user now, which may still be authorized
> by group membership for instance, ie: "AllowGroups ssh"


Yep, UID 0 of course, the username doesn't matter.

>> you wouldn't run selinux with it enabled?


> Well one of the points of SELinux seems (to me) to be there isn't any
> superuser, just accounts with some privilege or other (like in VMS).
> However i don't know how far allong that concept is currently. In such a
> system though (AFAIK/IME) there is/are accounts that can jump to any other
> account, and/or add/modify any privileges at will ... Just not without it
> getting logged (or better yet: having a directly connected system console.)


From what I tested, disabling selinux completely was the quickest
way getting back a working server. ;-)

>> You won't stop anyone serious from 'awk -F: '$3==0' /etc/passwd',


> But then they have a local account (or atleast they 'd have tricked
> some-one/-thing into providing that info) already.


Sure, if remote sshd access isn't allowed and the system is
physical secure, you'd need a local account, meaning it doesn't
help to map "root" to another UID.

>> but might break unintentional one or another script.


> I can see that for rc scripts doing a "su - -c <something>" or similar,
> which can be modified. But other scripts /probably/ should actually check
> for the (E)UID rather then username anyways (for SELinux though better to
> just execute something, and check the retuncode if it worked.)


I'd agree in an ideal world.

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 419: Repeated reboots of the system failed to
solve problem
Reply With Quote