Forum Replies Created
-
AuthorPosts
-
tecnobabble
ParticipantSo, I’ve been up to my ears in white papers and documentation and from the Apple Leopard Security doc linked a few posts above, it has an appendix ( B ) with security scripts in it.
They list:
[code]defaults write /Library/Preferences/com.apple.alf loggingenabled 1
defaults write /Library/Preferences/com.apple.alf stealthenabled 1
defaults write /Library/Preferences/com.apple.alf globalstate -int 1[/code]as the proper way to do it.
Enabling this in ONLY the logout script seems to hold between reboots etc. Through MCX there appears to be an issue of it reseting to the defaults if done via plist editing (on any setting, once, often or always) or in a login script.
My guess is that if you did something like:
To Stop:
[code]launchctl unload /System/Library/LaunchAgents/com.apple.alf.useragent.plist
launchctl unload /System/Library/LaunchDaemons/com.apple.alf.agent.plist[/code]To start:
[code]launchctl load /System/Library/LaunchDaemons/com.apple.alf.agent.plist
launchctl load /System/Library/LaunchAgents/com.apple.alf.useragent.plist[/code]Then we could get it to make those changes on login/logout and set those launch daemon/agent plists via MCX…
Though, in theory, a logout script makes sense though, because you’d want the machine to be protected on startup and sitting at login too; couple this with disabling fast user switching and you’re set. … right? 😀
Just don’t let your user’s be Admins, right knowmad?
tecnobabble
ParticipantI’m not sure about the prefs sitting in /usr, there is a entry in there to read the old prefs, my guess is that it’s just reading the /Library/Preferences/com.apple.alf plist.
Speaking of which, I’m going crazy. I swear none of this worked over the past 3-4 weeks.
Adding the following to my logout hook works; but only reliably (I think, starting to imagine gremlins inside the OS) if you enable the firewall last.
[code]defaults write /Library/Preferences/com.apple.alf loggingenabled -int 1
defaults write /Library/Preferences/com.apple.alf stealthenabled -int 1
defaults write /Library/Preferences/com.apple.alf globalstate -int 1[/code]I’m so confused, but it works so… 😛
tecnobabble
ParticipantSo I have a kinda solution to this.
Using MCX, create a logout script that writes:
defaults write /Library/Preferences/com.apple.alf globalstate 1
this will ensure that it’s on when the system boots and before any users login. I’m getting mixed results with the other firewalls settings (stealthmode and enablelogging) and putting it in a login hook, but will report back later.
tecnobabble
ParticipantRight, I know about the ipfw, the issue is that we need the application firewall due to the client management software that we’re running (or soon will be) on the machine. It depends on the signed app being recognized.
So any thoughts on why the com.apple.alf prefs aren’t being read? They’re being written, but don’t look like they’re enabled in the GUI, and from the limited testing, aren’t actually on. So the gui is reflecting what’s actually on the machine (no change to firewall on/off/limited, no loggining, no stealth), but the prefs show that all of it is turned on.
tecnobabble
Participantsystem.services.directory.configure is the one you want; change the group to something other than admin, perhaps a group that your own admin account is a part of and nobody else? This will prevent anybody using from using the Directory Utility to mess with root. (or anything else for that matter)
My test group was named blueberry.
Of note, this does nothing to prevent an admin from authenticating against dsenableroot. That still works if your an admin.
tecnobabble
ParticipantI’d look in /etc/authorization… my guess it’s something you can set there.
tecnobabble
Participantknowmad beat me to it. But he’s right.
I’m importing the com.apple.alf.plist into Workgroup Manager and setting the following:
globalstate 1
loggingenabled 1
stealthenabled 1They just don’t seem to have any effect on reboot; all the other mcx settings run fine.
Thought it might be something to do with the lack of an -int in the normal defaults write and that the system starts the firewall before the mcx settings are placed, but then you’d figure that it’d work after a second reboot.
Nada.
Thoughts?
p.s. I took the leap into mcx about 18 hours ago, and have not slept since… so bear with me.
-
AuthorPosts
Recent Comments