Question about SELinux and root privs

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?

I don't want to learn or mess about with miles and miles of SELinux
stuff, just make sure if someone is in as root, they can have fun and
run xtetris, but not rm -rf / etc.
Naurally, I'd like control over exactly what they can and can't do if I
*want* to, but with minimal messing about, I just want to ensure they
can't do anything to mess up the normal working of the machine.


Thanks.

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.

Don't let the bad guys do that.

--
Pat

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

> Don't let the bad guys do that.

I presume you mean: if(geteuid())

--
-Menno.

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, you wouldn't run
selinux with it enabled? You won't stop anyone serious from 'awk
-F: '$3==0' /etc/passwd', but might break unintentional one or
another script.

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 157: Incorrect time synchronization

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"

> 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.)

> 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.

> 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.)

--
-Menno.

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

On Wed, 28 Dec 2005 22:30:26 +0100, Michael Heiming wrote:
> In comp.os.linux.security Menno Duursma <menno@desktop.lan>:

>> 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. ;-)

Same here: in FC3 it broke running snmpd under it's own account. And it
looked to time consuming for us to fix the policy to allow it setuid().

>>> 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.

I think that answers the OP question though.

--
-Menno.