found way around chmod o=r

T

twist3dfear

I was messing around trying to secure a directory for a contest my school is doing. Well I thought i would go to the master(wheel) account and the the su command to switch to root. I found out root can go around chmod o=r. So I was wondering if anyone knew a way to stop that. I figured I could try and secure the master(wheel) account. Any suggestions?

Thank ya and have a nice day
Twist3dfear
 
twist3dfear said:
I found out root can go around chmod o=r.
Click to expand...
root can go around anything and everything.

So I was wondering if anyone knew a way to stop that.
Click to expand...
The only way would be to implement MAC (Mandatory Access Control).

In a sense this is actually one of the reasons why the Windows security model is better then *nix. On Windows you can set an ACL that blocks access for Administrators. Something you simply cannot do on *nix without implementing MAC.
 
As SirDice had stated, root can do anything and everything.

You can however use the chflags() command to 'lock' directories/files from being modified ( chown, chmod). But of course, since you're root, you can always remove the flag to 'unlock' the directories/files.

If you want to secure directories, just assign correct permissions on them, and don't add other users to the wheel account so that they can't $ su to root (they're not supposed to know the password anyway).
 
sixtydoses said:
You can however use the chflags() command to 'lock' directories/files from being modified ( chown, chmod). But of course, since you're root, you can always remove the flag to 'unlock' the directories/files.
Click to expand...

If you raise securelevel to 1 or higher not even root can change it remotely. You will need physical access to the console and drop to single user mode to change the flags.
 
In a sense this is actually one of the reasons why the Windows security model is better then *nix. On Windows you can set an ACL that blocks access for Administrators. Something you simply cannot do on *nix without implementing MAC.
Click to expand...

Administrators can re-enable access, or take ownership and re-enable access.
On UNIX you can chflag. Which would prevent programs and stuff running under root UID messing with some important files. And then you can chflag again and re-enable access.

Actually, disabling Administrators access in Windows NT comes to one thing only; NT is really crap when it comes to multi-user implementation. A lot of stuff needs to be ran under administrative privileges, and then Administrators can cut down their own privileges so buggy programs wouldn't harm the system.

And, it's not even Windows NT secutiry model. It's VMS security model.

Basically the main difference is between Administrator and root. Administrator doesn't have god-like privileges, root has. But that's quite absurd, because NT Administrator account can easily initiate commant prompt running under 'LOCAL SYSTEM' user, and there you go, you have root.

Fine grained permissions were the highlight of VMS security model, and we have them on UNIX too.
 
Zare said:
Administrators can re-enable access, or take ownership and re-enable access.
Click to expand...
Close but not quite. To get access an administrator would need to take ownership of the files. Then s/he might be able to change the ACL. However (this is the other point why the windows model is beter) an administrator cannot give ownership to someone else. Root can.

Actually, disabling Administrators access in Windows NT comes to one thing only; NT is really crap when it comes to multi-user implementation. A lot of stuff needs to be ran under administrative privileges, and then Administrators can cut down their own privileges so buggy programs wouldn't harm the system.
Click to expand...
You really need to have a look at something more recent then NT4. You also need to get "properly" implemented third party software. The last can be a big problem but that's hardly Microsoft's fault, the documentation on how to do it properly has been available for years.

Basically the main difference is between Administrator and root. Administrator doesn't have god-like privileges, root has.
Click to expand...
Which means windows is more secure as a rogue administrator is never able to 'hide' what s/he did. On a *nix system this is quite easy to do.

But that's quite absurd, because NT Administrator account can easily initiate commant prompt running under 'LOCAL SYSTEM' user, and there you go, you have root.
Click to expand...
Not on recent versions of Windows.
 
thanks guys this helps alot. But i'm not sure if I stated this earlier but this is for a contest at my school with other schools and yea. So the "master" account is the only one who can access root. cause I tried to do it with other acounts. So is there a good way to lock down the account then? Because my server and such is being tested from college computer science graduates. Thanks again for replying
 
And set a password on single-user mode (set console to insecure in /etc/ttys).
 
securelevel is powerful but the fact I need to reboot to back out of it stops me using it.

I would love some kind of intermediate solution where a protective layer is in place to stop chflags, sysctl etc. however this layer does not need a reboot or console access to cancel it out.

obviously adding a weakened version of securelevel adds risks but it is still better than no securelevel at all.
 
What level of access do the testers have and what is their goal (to get the root account, download stuff)?

Assuming they only have remote user-level access, this is what I would do:

Create separate mount points for /home and /tmp (the 2 partitions that regular users have write access to).
Set those mount points with the following options:
noexec, nosuid

This should make it relatively difficult for normal users to compile anything on the localhost that would result in something they can run.

Audit the setuid/setgid binaries on the system and remove ones you don't need (or remove the setuid bit).

Install a firewall with user/group filtering (ipfw(8)) that allows you to dictate what network connections they are allowed to setup.

Increase the kern.securelevel sysctl to 3 to prevent anyone from tampering with the firewall rules or system flags.

In all, read the security(7) page and figure out how to implement as many layers of security as possible.
 
gordon@ said:
Install a firewall with user/group filtering (ipfw(8)) that allows you to dictate what network connections they are allowed to setup.
Click to expand...

pf(4) can do that as well. In fact, I'm using it.

Code: 
[...]

    user <user>
           This rule only applies to packets of sockets owned by the specified
           user.  For outgoing connections initiated from the firewall, this
           is the user that opened the connection.  For incoming connections
           to the firewall itself, this is the user that listens on the desti-
           nation port.

    group <group>
           Similar to user, this rule only applies to packets of sockets owned
           by the specified group.

[...]
 
SirDice said:
Which means windows is more secure as a rogue administrator is never able to 'hide' what s/he did. On a *nix system this is quite easy to do.
Click to expand...

No it isn't, if your logging mechanism is completely chflagged and you have appropriate kernel securelevel setting.

SirDice said:
Not on recent versions of Windows.
Click to expand...

Wrong again. You cannot directly run command prompt as LOCALSYSTEM because that account doesn't have access to windowstation, but you can register a program that's local socket console relay with SCM and that's it.

Or you can use some of fine Sysinternals tools called psexec, and then you can run any program as Windows equivalent of root.

Windows security model is overbloated bullshit that just gets on administrator's nerves and stops them from doing real work fast, while at same time it doesn't provide any better hacking protection than traditional UNIX + ACLs.
 
You must log in or register to reply here.
Back
Top