Forum Replies Created

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • in reply to: Firewall settings and MCX #375921
    tecnobabble
    Participant

    So, 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?

    in reply to: Firewall settings and MCX #375904
    tecnobabble
    Participant

    I’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… 😛

    in reply to: Firewall settings and MCX #375899
    tecnobabble
    Participant

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

    in reply to: Firewall settings and MCX #375637
    tecnobabble
    Participant

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

    in reply to: root and the managed environment #375625
    tecnobabble
    Participant

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

    in reply to: root and the managed environment #375624
    tecnobabble
    Participant

    I’d look in /etc/authorization… my guess it’s something you can set there.

    in reply to: Firewall settings and MCX #375621
    tecnobabble
    Participant

    knowmad 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 1

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

Viewing 7 posts - 1 through 7 (of 7 total)