Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
29,866 posts in this topic

Recommended Posts

joe75
joe75
Posted
Posted

Me too, but what you say is like: "Hey. I never had problems with security holes so let's not care and apply any security patches (updates)."

 

That wasn't my point at all.

 

I was referring to leaving SIP disabled as not being a concern to me, other people will do as they wish. As long as I can disable what I want I don't really care what Apple adds.

Link to comment
Share on other sites
MTWomg
MTWomg
Posted
Posted (edited)

Me too, but what you say is like: "Hey. I never had problems with security holes so let's not care and apply any security patches (updates)."

 

Security holes != disabling a new security feature that is of little to no benefit to technically proficient users. 

 

And we're talking about DEFAULTS. Off on a hackintosh = a good default.

 

EDIT: Moderator queue nonsense is making it hard to respond to you, so let's see if this works:

 

1. Being technically proficient means you don't give root pw to any app that asks for it, making SIP moot. The things SIP breaks aren't worth 'security' that provides nothing to said user. Security is responsibility. Responsibility is not running dodgy things. 

 

2. Running a hack makes everything different. Third party bootloader + unsigned kexts + god knows what else (user specific). You punched a hole in a wall and are trying to patch it back up with tape so it's 'just like new'. That isn't a winning strategy. 

 

3. Yes, SIP exists as normal users give PW to any app that asks for it. I do not need computer training wheels, same for the vast majority of the Clover user base. We expect any app ran as root to be able to do anything it wants, and act accordingly. 

 

4. You have absolutely zero way of knowing what future Apple products will do (hints in code does not equal knowing the future) nor is it relevant. 

Edited by Micky1979
  • Like 1
Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

Security holes != disabling a new security feature that is of little to no benefit to technically proficient users.

 

And we're talking about DEFAULTS. Off on a hackintosh = a good default.

Sorry, but what has: "being technically proficient" to do with this? Running a hack should be no different when it comes down to security.

 

Also. SIP didn't fall out of the sky for nothing you know. Exploits are there and are actively being used in the wild. That is why Apple is doing this. To keep your data/money safe, out of the hands of attackers. Also. New series of Apple products will also be even more strict and come with new EFI that won't load anything that isn't signed. Including boot.efi

  • Like 2
Link to comment
Share on other sites
tachikaze
tachikaze
Posted
Posted

Setting CsrActiveConfig to 0x1 should set kext-dev-mode only (keeping the other rootless features), correct?

 

yup, assuming booting into e.g. Yosemite can handle the copying of kexts into /L/E, hackintoshing 10.11 is currently hanging by that single bit : )

Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted

Setting CsrActiveConfig to 0x1 should set kext-dev-mode only (keeping the other rootless features), correct?

It should set CSR_ALLOW_UNTRUSTED_KEXTS to 1. I'm not sure kext-dev-mode is still used in 10.11. But I might be wrong.

Anyway, as a result, yes, you should be able to load unsigned kexts, while keeping the other features "locked".

 

Update:

 

Guys, I think I might have found the reason for the unsuccessful shut downs I mentioned above: nvda_drv=1. The Nvidia driver is installed so I thought I should put that in the config, as well. But it seems to be causing problems (might be because of the driver itself, but still, that doesn't explain the behavior below).

 

Now, interestingly enough, even after removing it from config.plist, it's still loaded at startup. So, in order not to load it, I need to go into Clover Options, remove it from Boot Args and then boot. Which seems to work. And of course, I need to do that for every boot. But...why is it still there? Where does it come from? 

 

post-1303722-0-82235900-1438587088_thumb.jpg post-1303722-0-92376400-1438587099_thumb.png post-1303722-0-45903400-1438587107_thumb.png

 

Yes, I'm still using kext-dev-mode=1 for Yosemite.

Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

What I see are many different thoughts, but they all trying to prove something, and to me this more for war than for a healthy discussion where not led to anything. my 2 cents.

Thanks for the warning Mirone, but it's not my personal view but that of security researchers and Apple. – though it is not my task to make people aware of ignorant views so I refrain from commenting on the issue. To each his own.
Link to comment
Share on other sites
magnifico
magnifico
Posted
Posted

JFYI I have my kexts in /kexts and kextload them with an rc.server script, works with csr-active-config %00%00%00%00

 

edit:

Even though I use Ozmosis, this should work for Clover/Chameleon/Revoboot or any boot.

can you explain in more detail?
Link to comment
Share on other sites
VCH888
VCH888
Posted
Posted

 

Now, interestingly enough, even after removing it from config.plist, it's still loaded at startup. So, in order not to load it, I need to go into Clover Options, remove it from Boot Args and then boot. Which seems to work. And of course, I need to do that for every boot. But...why is it still there? Where does it come from? 

 

You want to remove nvda_drv=1, don't you. It might be in nvram.plist since to enable NVIDIA web driver from NVIDIA Driver Manager.

 

Terminal:

 

nvram -p

 

if it has nvda_drv=1, then type sudo nvram -c

 

after that restart your system.

  • Like 3
Link to comment
Share on other sites
Allan
Allan
Posted
Posted

You want to remove nvda_drv=1, don't you. It might be in nvram.plist since to enable NVIDIA web driver from NVIDIA Driver Manager.

 

Terminal:

 

nvram -p

 

if it has nvda_drv=1, then type sudo nvram -c

 

after that restart your system.

 

Or erase the entire boot-args values in Nvram:

nvram -d boot-args
  • Like 3
Link to comment
Share on other sites
stinga11
stinga11
Posted
Posted 
0x03 (00000011)
1 CSR_ALLOW_UNTRUSTED_KEXTS 
1 CSR_ALLOW_UNRESTRICTED_FS
0 CSR_ALLOW_TASK_FOR_PID
0 CSR_ALLOW_KERNEL_DEBUGGER
0 CSR_ALLOW_APPLE_INTERNA
0 CSR_ALLOW_UNRESTRICTED_DTRACE
0 CSR_ALLOW_UNRESTRICTED_NVRAM
 
    <key>RtVariables</key>
    <dict>
        <key>CsrActiveConfig</key>
        <string>0x03</string>
        <key>BooterConfig</key>
        <string>0x28</string>
    </dict>

Hey Guys, Can I use this Value ??? to accept kext unsigned and to put the kext in s/l/e ???

Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted 
0x03 (00000011)1 CSR_ALLOW_UNTRUSTED_KEXTS 1 CSR_ALLOW_UNRESTRICTED_FS0 CSR_ALLOW_TASK_FOR_PID0 CSR_ALLOW_KERNEL_DEBUGGER0 CSR_ALLOW_APPLE_INTERNA0 CSR_ALLOW_UNRESTRICTED_DTRACE0 CSR_ALLOW_UNRESTRICTED_NVRAM     <key>RtVariables</key>    <dict>        <key>CsrActiveConfig</key>        <string>0x03</string>        <key>BooterConfig</key>        <string>0x28</string>    </dict>
Hey Guys, Can I use this Value ??? to accept kext unsigned and to put the kext in s/l/e ???

Yes, you can.

 

Don't forget to set permissions to the kexts you add.

You can put the kexts pretty much anywhere you have the right to read and write. I got them in L/E though, instead of S/L/E.

 

UPDATE:

 

Well, you're gonna like this: there is no nvda_drv in NVRAM.

  • Like 1
Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted

You forgot that some people have hardware nvram and need no nvram.plist. Me for example.

Hi Sergey. :) So any idea for my hardware then? I don't have nvda_drv in nvram plist. So, trying to remove it from there...didn't do much for me.

 

I'm not sure this is NVRAM related (although, of course, I might be wrong). The reason why I'm not sure this is NVRAM related is that when I removed rootless=0 from config, I didn't have this issue of still seeing it when booting up. I removed it, it was removed for good. So...why would it be any different for nvda_drv=1? Any idea?

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Hi Sergey. :) So any idea for my hardware then? I don't have nvda_drv in nvram plist. So, trying to remove it from there...didn't do much for me.

 

I'm not sure this is NVRAM related (although, of course, I might be wrong). The reason why I'm not sure this is NVRAM related is that when I removed rootless=0 from config, I didn't have this issue of still seeing it when booting up. I removed it, it was removed for good. So...why would it be any different for nvda_drv=1? Any idea?

Make a dump of your nvram.

Make DarwinDump. Then we will see what is what.

Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted

Make a dump of your nvram.

Can I use DarwinDumper for that? If not, how do I do that? Sorry for the noob questions but I've never done that before.

Make DarwinDump. Then we will see what is what.

How do I do that? Again...sorry but I have no idea how to do that. I only used Darwin Dumper once to dump EDID. After that....nope. So, you're speaking klingon to me. I think I would better understand Russian than this. :)) And even though I do know the alphabet and a few words, I can't say I speak Russian.

 

So..how do I do this? :D

Link to comment
Share on other sites
Riley Freeman
Riley Freeman
Posted
Posted

Run "nvram -px" from Terminal and look for boot-args. See if it's there.

 

If it is, you can delete the boot-args section with "sudo nvram -d boot-args".

 

You might need to have allowed unrestricted nvram via csr for this to work, I'm not sure.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...