Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

?....???

1.1.1.1 is the main Cloudflare DNS server, 1.1.1.3 is the one that blocks malware and adult content. You will figure out the rest :)

DNScache.jpg
 
thanks a ton!

so will that -setdnsservers, which i guess will be the same as if i did change the DNS in the macOS network settings, completely override the DNS server settings of my router?
 
thanks, i was using ping and traceroute, but in the end, if i'm not feeling laggier connections i'm fine with it.
before this query, i was using my ISP router's default DNS, now i've set that to Quad9 for the moment, but it's nice to know that you can easily change that with a simple change of your network location👍
 
hello again

i''ve had the idea for a while to create a non-sudoer account for everyday tasks and chmod 700 the /bin, /sbin and /usr/bin directories in order to harden my system a bit.
stupid idea? won't help much / won't work, or will this cause trouble? or are there better ways?
 
unrigestered said:
hello again

i''ve had the idea for a while to create a non-sudoer account and chown root:admin and chmod 700 the
/bin
/sbin
/usr/bin
direcotries in order to harden my system a bit.
stupid idea? won't help much / won't work, or will this cause trouble? or are there better ways?
Click to expand...
Do not do this. The main result will be breakage. Then you'll have to reverse the breakage, and possibly make a mistake that results in worse security than if you'd left things alone.

Some of the breakage will be commands that are required to be owned by root, because they have the setuid bit set. For example, sudo and su need this. There may be others. If you don't know what the setuid bit is, or why it's important, you can read about it. For further reading, there's also a setgid bit.

Other things might break if they happen to check ownership of files, expecting it to be root.

I won't even guess what might happen at the next OS update installation. If you're lucky, it might reverse everything and do it correctly. If you're unlucky, it will try to run and fail, corrupting the OS in the process. Somewhere between, it would see the unexpected ownership and refuse to run.
 
  • Like
Reactions: chengengaun and gilby101
thanks!
i remember reading about the UIDs before and thought that those might be key too, but i think i hadn't found a solution regarding this

never heard of GID until now, but those are probably the group IDs

off to some more research... 👍
 
chown33 said:
Do not do this. The main result will be breakage. Then you'll have to reverse the breakage, and possibly make a mistake that results in worse security than if you'd left things alone.
Click to expand...

100% agree with this. Thumbs up for using an account that's not an admin for regular activities but a hard "no" for changing file permissions on system directories.
 
thanks, but what exactly is the security benefit in "just" using a non-admin account in daily usage then?
for installations you will need to confirm your choice with your system / sudo password anyway, my thinking was more to suppress some sneaky curl / mkdir / cp, etc. activities in the background exactly when i'm not trying to install anything at all.
but that method i was thinking of would actually be way too easy and would long have been implemented by UNIX-like systems if it was possible.
 
unrigestered said:
thanks, but what exactly is the security benefit in "just" using a non-admin account in daily usage then?
for installations you will need to confirm your choice with your system / sudo password anyway, my thinking was more to suppress some sneaky curl / mkdir / cp, etc. activities in the background exactly when i'm not trying to install anything at all.
but that method i was thinking of would actually be way too easy and would long have been implemented by UNIX-like systems if it was possible.
Click to expand...

It doesn't even have to be something sneaky. It can prevent you from yourself. As admin you might have permission to shoot yourself in the foot by deleting/changing things you shouldn't.
 
hmm, in the decades i've been using computers i don't think i've ever needed to be saved from myself, as i'm usually pretty careful (see this bin query)

having said that... i think i'll finally try exactly this out later today
(on a Linux Live USB Stick though 🐓)
 
will blocking the Terminal prevent the execution of those commands?
of course i chmodd'ed /bin on Linux, not macOS, but by doing so i successfully bricked the whole OS (thankfully it was just a test install), so it seems that these commands are more than just some function calls only available via the terminal.

and if it does... wouldn't chmod -R on Terminal.app basically result in same as Santa?
 
unrigestered said:
wouldn't chmod -R on Terminal.app basically result in same as Santa?
Click to expand...
You can’t chmod Terminal because it’s on the read-only system volume.
Virtual Machine with Ventura 13.3.1 (a) (22E772610a) Santa 2023.4
Blocking ls from executing
Block_ls.jpg
Code: 
which ls
shasum -a 256 /bin/ls
sudo santactl rule --block --path /bin/ls --sha256 af1f2453969207ce093d812708077297621d6b7038adf70f6ff4e10084d9e062

sudo santactl rule --remove --path /bin/ls --sha256 af1f2453969207ce093d812708077297621d6b7038adf70f6ff4e10084d9e062

Blocking sudo
block_sudo.jpg
The rule for sudo can be removed from Script Editor with
Code: 
do shell script "/usr/local/bin/santactl rule --remove --path /usr/bin/sudo --sha256 7cec156bbcc5f064a09bb294d1031ee198f0911b4f330239f6a820a39a174ec0" with administrator privileges
 
You can’t chmod Terminal because it’s on the read-only system volume.
Click to expand...
yes, i was aware that this might be the case.
but when i checked, Finder tells me it's location is in /Applications/Utilities, so i became unsure.
when i ls that folder in the Terminal, that folder is empty though, except for the two applications i copied there myself.. i guess those links are located on that system volume.

there's similar possibilities like Santa on Linux, even natively inside the OS (at least in some), among other stuff like SELinux, which i might have to look further into.

my question was though, as you mentioned before that Santa could block Terminal, if scripts really require the terminal to be open those commands. i never do scripts, but i never noticed any such requirement.
but this later example example you gave shows, that also those commands can be clocked.

in the end i'm really just a novice when it comes to system security though. i just thought that it might be a good idea to lock out possible maliciously exploitable "invisible" entry points inside some script of which i'm not even alerted of, as basically anyone has the rights to curl, etc.
i'm fully expecting to be asked for the admin password when i'm installing something, or do more critical things on the system configuration, but i might become suspicious if it popped up during web browsing because of some command execution everyone has unrestricted access to per default.
but UNIX (clones) have been used for so long by people MUCH smarter than me, and they seemingly thought that this shouldn't really be such an issue, so i'm basically ok with this behavior too i guess.

and the OS seems to actually require those commands available to anyone anyway (at least on Linux), as the only things i could still do is closing the terminal and funnily opening the calendar. pretty much no other app would run, and entering commands inside the terminal ended with a request to install the package that includes sed.
which of course could not be executed either, as those commands to curl, etc. were not available either.
i couldn't even do a regular shutdown anymore, though i hadn't tried the shutdown command inside the /sbin folder that i hadn't chmodded yet, before i closed that terminal window.

i might tinker with it some more on a new test install, but not on the highest priority as i am sadly occupied by other things at the moment.
this time probably on a VM though
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back