Re: weekly periodic security status

2013-08-27 Thread Jeremie Le Hen 
Hi Darren,

On Mon, Aug 26, 2013 at 06:11:04PM -0400, Darren Pilgrim wrote:
 On 8/26/2013 5:09 PM, Jeremie Le Hen wrote:
  On Mon, Aug 26, 2013 at 12:29:30PM -0400, Darren Pilgrim wrote:
  The new framework would let me rely on the environment instead of $0,
  which, IMO, is more reliable.  I'd need to be able to tell periodic to
  run that script with the daily, weekly and monthly security runs, though.
 
  If I understand what you say correctly, this should continue to work.
 
 As I understand the framework, I can only set the enable to NO, 
 daily, weekly or monthly.  Periodic will only run it one of the 
 periods.  How would I set it to run in all three?  How would I set to 
 run in only two of the three periods?
 
 It seems like you could add this functionality by adding stars to each 
 end of the case patterns in check_yesno_period.

I've committed my work.  Can you propose me a patch implementing what
you request please?

Thanks,
-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-26 Thread Julian Elischer 

On 8/25/13 7:05 PM, Jeremie Le Hen wrote:


And the following variables to control whether you want each check to
run daily, weekly or directly from crontab (the default, backward
compatible values are shown):
 security_status_chksetuid_enable=daily
 security_status_neggrpperm_enable=daily
 security_status_chkmounts_enable=daily
 security_status_chkuid0_enable=daily
 security_status_passwdless_enable=daily
 security_status_logincheck_enable=daily
 security_status_chkportsum_enable=NO
 security_status_ipfwdenied_enable=daily
 security_status_ipfdenied_enable=daily
 security_status_pfdenied_enable=daily
 security_status_ipfwlimit_enable=daily
 security_status_ipf6denied_enable=daily
 security_status_kernelmsg_enable=daily
 security_status_loginfail_enable=daily
 security_status_tcpwrap_enable=daily


excellent..

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-26 Thread RW 
On Sun, 25 Aug 2013 22:03:58 +0200
Jeremie Le Hen wrote:

 I've implemented it here:
 http://people.freebsd.org/~jlh/security_status_period.diff
 

Doesn't this mean that if you want to run periodic security from
crontab or manually etc, you have to override every single entry to
crontab in period.conf.

IMO when periodic security is run directly every test should run
unless it's explicitly set to NO. 

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-26 Thread Jeremie Le Hen 
On Mon, Aug 26, 2013 at 05:03:32PM +0100, RW wrote:
 On Sun, 25 Aug 2013 22:03:58 +0200
 Jeremie Le Hen wrote:
 
  I've implemented it here:
  http://people.freebsd.org/~jlh/security_status_period.diff
  
 
 Doesn't this mean that if you want to run periodic security from
 crontab or manually etc, you have to override every single entry to
 crontab in period.conf.
 
 IMO when periodic security is run directly every test should run
 unless it's explicitly set to NO. 

You are right, I've updated the patch accordingly.  Thanks for your
review.

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-26 Thread Darren Pilgrim 

On 8/25/2013 1:37 PM, Jeremie Le Hen wrote:

Hi Darren,

On Sun, Aug 25, 2013 at 12:45:22PM -0400, Darren Pilgrim wrote:

On 8/25/2013 7:05 AM, Jeremie Le Hen wrote:

And the following variables to control whether you want each check to
run daily, weekly or directly from crontab (the default, backward
compatible values are shown):


What do we do if we want to run a check both daily and weekly?


I really don't see the point of running some checks weekly when you do
daily.  Do you have a particular example in mind?


On one set of systems, I have a log analyser run as a periodic script. 
 On a daily run, it grabs and filters logs into a database.  On weekly 
runs, it does some statistical analysis of the filtered logs in the 
database.  On monthly runs, it does a larger set of stats and a bit of 
housekeeping.  The script lives in /usr/local/libexec and is hardlinked 
into the /usr/local/etc/periodic/ subtree and cases out the value of $0.


The new framework would let me rely on the environment instead of $0, 
which, IMO, is more reliable.  I'd need to be able to tell periodic to 
run that script with the daily, weekly and monthly security runs, though.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-26 Thread Jeremie Le Hen 
Darren

On Mon, Aug 26, 2013 at 12:29:30PM -0400, Darren Pilgrim wrote:
  On 8/25/2013 7:05 AM, Jeremie Le Hen wrote:
  And the following variables to control whether you want each check to
  run daily, weekly or directly from crontab (the default, backward
  compatible values are shown):
 
  What do we do if we want to run a check both daily and weekly?
 
  I really don't see the point of running some checks weekly when you do
  daily.  Do you have a particular example in mind?
 
 On one set of systems, I have a log analyser run as a periodic script. 
   On a daily run, it grabs and filters logs into a database.  On weekly 
 runs, it does some statistical analysis of the filtered logs in the 
 database.  On monthly runs, it does a larger set of stats and a bit of 
 housekeeping.  The script lives in /usr/local/libexec and is hardlinked 
 into the /usr/local/etc/periodic/ subtree and cases out the value of $0.
 
 The new framework would let me rely on the environment instead of $0, 
 which, IMO, is more reliable.  I'd need to be able to tell periodic to 
 run that script with the daily, weekly and monthly security runs, though.

If I understand what you say correctly, this should continue to work.

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-26 Thread Darren Pilgrim 

On 8/26/2013 5:09 PM, Jeremie Le Hen wrote:

On Mon, Aug 26, 2013 at 12:29:30PM -0400, Darren Pilgrim wrote:

The new framework would let me rely on the environment instead of $0,
which, IMO, is more reliable.  I'd need to be able to tell periodic to
run that script with the daily, weekly and monthly security runs, though.


If I understand what you say correctly, this should continue to work.


As I understand the framework, I can only set the enable to NO, 
daily, weekly or monthly.  Periodic will only run it one of the 
periods.  How would I set it to run in all three?  How would I set to 
run in only two of the three periods?


It seems like you could add this functionality by adding stars to each 
end of the case patterns in check_yesno_period.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-25 Thread Jeremie Le Hen 
On Sat, Aug 24, 2013 at 06:03:37PM -0400, Eitan Adler wrote:
 On Sat, Aug 24, 2013 at 4:47 PM, Jeremie Le Hen j...@freebsd.org wrote:
  On Sat, Aug 24, 2013 at 10:41:56AM -0400, Eitan Adler wrote:
  On Thu, Aug 22, 2013 at 4:49 PM, Jeremie Le Hen j...@freebsd.org wrote:
   Well, whatever, if you have any concerns, objections or comments, please
   speak now :).
 
  This LGTM but please include a comment above the warning with a date /
  release number when this compatibility can be removed.
 
  If the old variable names are deprecated in releng/10, they can be
  removed in releng/11, can't they?
 
 Yes, and this should be indicated in a comment.  When I see
 deprecated or old hack or similar terms in code it takes some
 archaeology to figure out when it was added and when it could be
 removed.   It would be nice to help the future reader a bit.

The purpose of my question was to know what to put in the comment ;-).
Thanks for pointing this out.

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-25 Thread Jeremie Le Hen 
On Sat, Aug 24, 2013 at 06:57:04PM +0200, Jeremie Le Hen wrote:
 On Fri, Aug 23, 2013 at 08:35:55PM -0800, Royce Williams wrote:
  On Fri, Aug 23, 2013 at 10:44 AM, Darren Pilgrim 
  list_free...@bluerosetech.com wrote:
  
   Thank you for this, but if I may make one suggestion: don't combine all
   the security report settings--keep both daily_* and weekly_*.  This makes
   possible running some security tasks on a daily basis and others on a
   weekly basis.  For example, daily pkg/portaudit checks, but weekly
   filesystem scans.
  
  
  Agreed.  I welcome and would use the weekly option at this level of
  granularity, but would like to retain daily for many checks, and so would
  not use weekly if was an all-or-nothing option.
 
 Sounds like a good idea.  However I don't know how to implement this
 because, in the current state of the periodic security scripts, there is
 no way to know whether a script had been called from daily or weekly
 periodic scripts, so no way to know which variable to check.
 
 The easy way to work around this would be to declare an environment
 variable from 450.status-security, but it sounds like a hackish way
 because you create an additional dependency for the periodic security
 scripts.

I've modified periodic(8) to set the $PERIODIC environment variable in
r254829.

The attached patch does more or less what you requested, but slightly
differently.

We now have the following variables to control daily/weekly security
runs:
daily_status_security_enable=YES
daily_status_security_inline=NO
daily_status_security_output=root

weekly_status_security_enable=YES
weekly_status_security_inline=NO
weekly_status_security_output=root


And the following variables to control whether you want each check to
run daily, weekly or directly from crontab (the default, backward
compatible values are shown):
security_status_chksetuid_enable=daily
security_status_neggrpperm_enable=daily
security_status_chkmounts_enable=daily
security_status_chkuid0_enable=daily
security_status_passwdless_enable=daily
security_status_logincheck_enable=daily
security_status_chkportsum_enable=NO
security_status_ipfwdenied_enable=daily
security_status_ipfdenied_enable=daily
security_status_pfdenied_enable=daily
security_status_ipfwlimit_enable=daily
security_status_ipf6denied_enable=daily
security_status_kernelmsg_enable=daily
security_status_loginfail_enable=daily
security_status_tcpwrap_enable=daily


The periodic.conf(5) manpage and default/periodic.conf have been
updated accordingly, but I plan to further rework them after the patch
is committed (especially, grouping security related variable into their
own section).  That way the modification done by the patch remain clear.

Patch available here:
http://people.freebsd.org/~jlh/daily_or_weekly_status_security.diff


-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-25 Thread Royce Williams 
On Sun, Aug 25, 2013 at 3:05 AM, Jeremie Le Hen j...@freebsd.org wrote:

 On Sat, Aug 24, 2013 at 06:57:04PM +0200, Jeremie Le Hen wrote:
  On Fri, Aug 23, 2013 at 08:35:55PM -0800, Royce Williams wrote:
   On Fri, Aug 23, 2013 at 10:44 AM, Darren Pilgrim 
   list_free...@bluerosetech.com wrote:
  
Thank you for this, but if I may make one suggestion: don't combine
 all
the security report settings--keep both daily_* and weekly_*.  This
 makes
possible running some security tasks on a daily basis and others on a
weekly basis.  For example, daily pkg/portaudit checks, but weekly
filesystem scans.
   
  
   Agreed.  I welcome and would use the weekly option at this level of
   granularity, but would like to retain daily for many checks, and so
 would
   not use weekly if was an all-or-nothing option.
 
  Sounds like a good idea.  However I don't know how to implement this
  because, in the current state of the periodic security scripts, there is
  no way to know whether a script had been called from daily or weekly
  periodic scripts, so no way to know which variable to check.
 
  The easy way to work around this would be to declare an environment
  variable from 450.status-security, but it sounds like a hackish way
  because you create an additional dependency for the periodic security
  scripts.

 I've modified periodic(8) to set the $PERIODIC environment variable in
 r254829.

 The attached patch does more or less what you requested, but slightly
 differently.

 We now have the following variables to control daily/weekly security
 runs:
 daily_status_security_enable=YES
 daily_status_security_inline=NO
 daily_status_security_output=root

 weekly_status_security_enable=YES
 weekly_status_security_inline=NO
 weekly_status_security_output=root


 And the following variables to control whether you want each check to
 run daily, weekly or directly from crontab (the default, backward
 compatible values are shown):
 security_status_chksetuid_enable=daily
 security_status_neggrpperm_enable=daily
 security_status_chkmounts_enable=daily
 security_status_chkuid0_enable=daily
 security_status_passwdless_enable=daily
 security_status_logincheck_enable=daily
 security_status_chkportsum_enable=NO
 security_status_ipfwdenied_enable=daily
 security_status_ipfdenied_enable=daily
 security_status_pfdenied_enable=daily
 security_status_ipfwlimit_enable=daily
 security_status_ipf6denied_enable=daily
 security_status_kernelmsg_enable=daily
 security_status_loginfail_enable=daily
 security_status_tcpwrap_enable=daily


 The periodic.conf(5) manpage and default/periodic.conf have been
 updated accordingly, but I plan to further rework them after the patch
 is committed (especially, grouping security related variable into their
 own section).  That way the modification done by the patch remain clear.

 Patch available here:
 http://people.freebsd.org/~jlh/daily_or_weekly_status_security.diff


This approach creates the granularity that I was looking for, and
represents a non-trivial amount of work; thanks for taking this on!

I haven't looked closely at the patch, but I do have a couple of style
comments.

If someone uses an unrecognized value the config, the phrase this is
incorrect, while strictly accurate, is a little harsh (and less
FreeBSD-ish, I think). I would expect something more along the lines of
Valid values are now (daily|weekly|NO). See periodic.conf(5) for more
details.  This gives the user the minimum information, leaves breadcrumbs
... and is a little less potentially pejorative. :-)

Also, while I see the utility in toggling daily/weekly in the *_enable
variables, how much precedent is there for overloading *_enable in this
way?  It's the first time that I've seen it, and may be a mild POLA
violation.  Most scripts seem to use *_enable solely as a binary YES/NO
toggle, and then modify script behavior with other variables (perhaps
_period in this case?)  That would double the config size, though, so I
definitely see why you went this route.

Both of the above are closely related.  If the period was stored in a
different variable, and the default _period was daily, then the vast
majority of the user base would still be correct and Just Keep Working
... and only those interested in weekly updates would need to modify
anything.

Just my $0.04.

Royce
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-25 Thread Darren Pilgrim 

On 8/25/2013 7:05 AM, Jeremie Le Hen wrote:

And the following variables to control whether you want each check to
run daily, weekly or directly from crontab (the default, backward
compatible values are shown):


What do we do if we want to run a check both daily and weekly?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-25 Thread Jeremie Le Hen 
Hi Darren,

On Sun, Aug 25, 2013 at 12:45:22PM -0400, Darren Pilgrim wrote:
 On 8/25/2013 7:05 AM, Jeremie Le Hen wrote:
  And the following variables to control whether you want each check to
  run daily, weekly or directly from crontab (the default, backward
  compatible values are shown):
 
 What do we do if we want to run a check both daily and weekly?

I really don't see the point of running some checks weekly when you do
daily.  Do you have a particular example in mind?

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-25 Thread Jeremie Le Hen 
On Sun, Aug 25, 2013 at 07:39:25AM -0800, Royce Williams wrote:
 On Sun, Aug 25, 2013 at 3:05 AM, Jeremie Le Hen j...@freebsd.org wrote:
 
  On Sat, Aug 24, 2013 at 06:57:04PM +0200, Jeremie Le Hen wrote:
   On Fri, Aug 23, 2013 at 08:35:55PM -0800, Royce Williams wrote:
On Fri, Aug 23, 2013 at 10:44 AM, Darren Pilgrim 
list_free...@bluerosetech.com wrote:
   
 Thank you for this, but if I may make one suggestion: don't combine
  all
 the security report settings--keep both daily_* and weekly_*.  This
  makes
 possible running some security tasks on a daily basis and others on a
 weekly basis.  For example, daily pkg/portaudit checks, but weekly
 filesystem scans.

   
Agreed.  I welcome and would use the weekly option at this level of
granularity, but would like to retain daily for many checks, and so
  would
not use weekly if was an all-or-nothing option.
  
   Sounds like a good idea.  However I don't know how to implement this
   because, in the current state of the periodic security scripts, there is
   no way to know whether a script had been called from daily or weekly
   periodic scripts, so no way to know which variable to check.
  
   The easy way to work around this would be to declare an environment
   variable from 450.status-security, but it sounds like a hackish way
   because you create an additional dependency for the periodic security
   scripts.
 
  I've modified periodic(8) to set the $PERIODIC environment variable in
  r254829.
 
  The attached patch does more or less what you requested, but slightly
  differently.
 
  We now have the following variables to control daily/weekly security
  runs:
  daily_status_security_enable=YES
  daily_status_security_inline=NO
  daily_status_security_output=root
 
  weekly_status_security_enable=YES
  weekly_status_security_inline=NO
  weekly_status_security_output=root
 
 
  And the following variables to control whether you want each check to
  run daily, weekly or directly from crontab (the default, backward
  compatible values are shown):
  security_status_chksetuid_enable=daily
  security_status_neggrpperm_enable=daily
  security_status_chkmounts_enable=daily
  security_status_chkuid0_enable=daily
  security_status_passwdless_enable=daily
  security_status_logincheck_enable=daily
  security_status_chkportsum_enable=NO
  security_status_ipfwdenied_enable=daily
  security_status_ipfdenied_enable=daily
  security_status_pfdenied_enable=daily
  security_status_ipfwlimit_enable=daily
  security_status_ipf6denied_enable=daily
  security_status_kernelmsg_enable=daily
  security_status_loginfail_enable=daily
  security_status_tcpwrap_enable=daily
 
 
  The periodic.conf(5) manpage and default/periodic.conf have been
  updated accordingly, but I plan to further rework them after the patch
  is committed (especially, grouping security related variable into their
  own section).  That way the modification done by the patch remain clear.
 
  Patch available here:
  http://people.freebsd.org/~jlh/daily_or_weekly_status_security.diff
 
 
 This approach creates the granularity that I was looking for, and
 represents a non-trivial amount of work; thanks for taking this on!
 
 I haven't looked closely at the patch, but I do have a couple of style
 comments.
 
 If someone uses an unrecognized value the config, the phrase this is
 incorrect, while strictly accurate, is a little harsh (and less
 FreeBSD-ish, I think). I would expect something more along the lines of
 Valid values are now (daily|weekly|NO). See periodic.conf(5) for more
 details.  This gives the user the minimum information, leaves breadcrumbs
 ... and is a little less potentially pejorative. :-)
 
 Also, while I see the utility in toggling daily/weekly in the *_enable
 variables, how much precedent is there for overloading *_enable in this
 way?  It's the first time that I've seen it, and may be a mild POLA
 violation.  Most scripts seem to use *_enable solely as a binary YES/NO
 toggle, and then modify script behavior with other variables (perhaps
 _period in this case?)  That would double the config size, though, so I
 definitely see why you went this route.
 
 Both of the above are closely related.  If the period was stored in a
 different variable, and the default _period was daily, then the vast
 majority of the user base would still be correct and Just Keep Working
 ... and only those interested in weekly updates would need to modify
 anything.
 
 Just my $0.04.

It's more than that, I really like your proposal.

I've implemented it here:
http://people.freebsd.org/~jlh/security_status_period.diff

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To

Re: weekly periodic security status

2013-08-25 Thread James Gosnell 
*Throughout the land, hard drives rejoice*


On Sun, Aug 25, 2013 at 3:03 PM, Jeremie Le Hen j...@freebsd.org wrote:

 On Sun, Aug 25, 2013 at 07:39:25AM -0800, Royce Williams wrote:
  On Sun, Aug 25, 2013 at 3:05 AM, Jeremie Le Hen j...@freebsd.org wrote:
 
   On Sat, Aug 24, 2013 at 06:57:04PM +0200, Jeremie Le Hen wrote:
On Fri, Aug 23, 2013 at 08:35:55PM -0800, Royce Williams wrote:
 On Fri, Aug 23, 2013 at 10:44 AM, Darren Pilgrim 
 list_free...@bluerosetech.com wrote:

  Thank you for this, but if I may make one suggestion: don't
 combine
   all
  the security report settings--keep both daily_* and weekly_*.
  This
   makes
  possible running some security tasks on a daily basis and others
 on a
  weekly basis.  For example, daily pkg/portaudit checks, but
 weekly
  filesystem scans.
 

 Agreed.  I welcome and would use the weekly option at this level of
 granularity, but would like to retain daily for many checks, and so
   would
 not use weekly if was an all-or-nothing option.
   
Sounds like a good idea.  However I don't know how to implement this
because, in the current state of the periodic security scripts,
 there is
no way to know whether a script had been called from daily or weekly
periodic scripts, so no way to know which variable to check.
   
The easy way to work around this would be to declare an environment
variable from 450.status-security, but it sounds like a hackish way
because you create an additional dependency for the periodic security
scripts.
  
   I've modified periodic(8) to set the $PERIODIC environment variable in
   r254829.
  
   The attached patch does more or less what you requested, but slightly
   differently.
  
   We now have the following variables to control daily/weekly security
   runs:
   daily_status_security_enable=YES
   daily_status_security_inline=NO
   daily_status_security_output=root
  
   weekly_status_security_enable=YES
   weekly_status_security_inline=NO
   weekly_status_security_output=root
  
  
   And the following variables to control whether you want each check to
   run daily, weekly or directly from crontab (the default, backward
   compatible values are shown):
   security_status_chksetuid_enable=daily
   security_status_neggrpperm_enable=daily
   security_status_chkmounts_enable=daily
   security_status_chkuid0_enable=daily
   security_status_passwdless_enable=daily
   security_status_logincheck_enable=daily
   security_status_chkportsum_enable=NO
   security_status_ipfwdenied_enable=daily
   security_status_ipfdenied_enable=daily
   security_status_pfdenied_enable=daily
   security_status_ipfwlimit_enable=daily
   security_status_ipf6denied_enable=daily
   security_status_kernelmsg_enable=daily
   security_status_loginfail_enable=daily
   security_status_tcpwrap_enable=daily
  
  
   The periodic.conf(5) manpage and default/periodic.conf have been
   updated accordingly, but I plan to further rework them after the patch
   is committed (especially, grouping security related variable into their
   own section).  That way the modification done by the patch remain
 clear.
  
   Patch available here:
   http://people.freebsd.org/~jlh/daily_or_weekly_status_security.diff
  
  
  This approach creates the granularity that I was looking for, and
  represents a non-trivial amount of work; thanks for taking this on!
 
  I haven't looked closely at the patch, but I do have a couple of style
  comments.
 
  If someone uses an unrecognized value the config, the phrase this is
  incorrect, while strictly accurate, is a little harsh (and less
  FreeBSD-ish, I think). I would expect something more along the lines of
  Valid values are now (daily|weekly|NO). See periodic.conf(5) for more
  details.  This gives the user the minimum information, leaves
 breadcrumbs
  ... and is a little less potentially pejorative. :-)
 
  Also, while I see the utility in toggling daily/weekly in the *_enable
  variables, how much precedent is there for overloading *_enable in this
  way?  It's the first time that I've seen it, and may be a mild POLA
  violation.  Most scripts seem to use *_enable solely as a binary YES/NO
  toggle, and then modify script behavior with other variables (perhaps
  _period in this case?)  That would double the config size, though, so I
  definitely see why you went this route.
 
  Both of the above are closely related.  If the period was stored in a
  different variable, and the default _period was daily, then the vast
  majority of the user base would still be correct and Just Keep Working
  ... and only those interested in weekly updates would need to modify
  anything.
 
  Just my $0.04.

 It's more than that, I really like your proposal.

 I've implemented it here:
 http://people.freebsd.org/~jlh/security_status_period.diff

 --
 Jeremie Le Hen

 Scientists say the

Re: weekly periodic security status

2013-08-24 Thread RW 
On Thu, 22 Aug 2013 22:49:58 +0200
Jeremie Le Hen wrote:

 Hi,
 
 I plan to commit the attached patch.  This allows the turn the daily
 security checks into weekly checks.  You do this by adding the
 following to periodic.conf(5):
 
 daily_status_security_enable=NO
 weekly_status_security_enable=YES
 
 All other $daily_status_security_whatever variables will be renamed to
 $security_status_whatever.  The old variable name is supported but
 prints a warning.
 

All daily_status_security_enable does is control whether the security
scripts are run from daily, but security is a periodic dirctory in its
own right.

You can simply set daily_status_security_enable=NO and put a
separate security entry in crontab (or anacrontab).   You can also
symlink the lightweight security scripts in a separate directory and
run those on all, or some, of the days you don't run the full security
pass.

In short the current support is more powerful and flexible than
anything suggested in this thread so far.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-24 Thread Eitan Adler 
On Thu, Aug 22, 2013 at 4:49 PM, Jeremie Le Hen j...@freebsd.org wrote:
 Well, whatever, if you have any concerns, objections or comments, please
 speak now :).

This LGTM but please include a comment above the warning with a date /
release number when this compatibility can be removed.


-- 
Eitan Adler
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-24 Thread Jeremie Le Hen 
On Fri, Aug 23, 2013 at 08:35:55PM -0800, Royce Williams wrote:
 On Fri, Aug 23, 2013 at 10:44 AM, Darren Pilgrim 
 list_free...@bluerosetech.com wrote:
 
  Thank you for this, but if I may make one suggestion: don't combine all
  the security report settings--keep both daily_* and weekly_*.  This makes
  possible running some security tasks on a daily basis and others on a
  weekly basis.  For example, daily pkg/portaudit checks, but weekly
  filesystem scans.
 
 
 Agreed.  I welcome and would use the weekly option at this level of
 granularity, but would like to retain daily for many checks, and so would
 not use weekly if was an all-or-nothing option.

Sounds like a good idea.  However I don't know how to implement this
because, in the current state of the periodic security scripts, there is
no way to know whether a script had been called from daily or weekly
periodic scripts, so no way to know which variable to check.

The easy way to work around this would be to declare an environment
variable from 450.status-security, but it sounds like a hackish way
because you create an additional dependency for the periodic security
scripts.

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-24 Thread Jeremie Le Hen 
On Sat, Aug 24, 2013 at 02:38:15PM +0100, RW wrote:
 On Thu, 22 Aug 2013 22:49:58 +0200
 Jeremie Le Hen wrote:
 
  Hi,
  
  I plan to commit the attached patch.  This allows the turn the daily
  security checks into weekly checks.  You do this by adding the
  following to periodic.conf(5):
  
  daily_status_security_enable=NO
  weekly_status_security_enable=YES
  
  All other $daily_status_security_whatever variables will be renamed to
  $security_status_whatever.  The old variable name is supported but
  prints a warning.
  
 
 All daily_status_security_enable does is control whether the security
 scripts are run from daily, but security is a periodic dirctory in its
 own right.
 
 You can simply set daily_status_security_enable=NO and put a
 separate security entry in crontab (or anacrontab).   You can also
 symlink the lightweight security scripts in a separate directory and
 run those on all, or some, of the days you don't run the full security
 pass.
 
 In short the current support is more powerful and flexible than
 anything suggested in this thread so far.

Nothing of what you say is wrong, but culturally I think it is more
common to configure things with variable assignments in configuration
files a-la rc.conf(5), rather than creating directories and symlinks.

I don't say one or the other is better, it is just a matter of
tradition.

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-24 Thread Jeremie Le Hen 
On Sat, Aug 24, 2013 at 10:41:56AM -0400, Eitan Adler wrote:
 On Thu, Aug 22, 2013 at 4:49 PM, Jeremie Le Hen j...@freebsd.org wrote:
  Well, whatever, if you have any concerns, objections or comments, please
  speak now :).
 
 This LGTM but please include a comment above the warning with a date /
 release number when this compatibility can be removed.

If the old variable names are deprecated in releng/10, they can be
removed in releng/11, can't they?

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-24 Thread Eitan Adler 
On Sat, Aug 24, 2013 at 4:47 PM, Jeremie Le Hen j...@freebsd.org wrote:
 On Sat, Aug 24, 2013 at 10:41:56AM -0400, Eitan Adler wrote:
 On Thu, Aug 22, 2013 at 4:49 PM, Jeremie Le Hen j...@freebsd.org wrote:
  Well, whatever, if you have any concerns, objections or comments, please
  speak now :).

 This LGTM but please include a comment above the warning with a date /
 release number when this compatibility can be removed.

 If the old variable names are deprecated in releng/10, they can be
 removed in releng/11, can't they?

Yes, and this should be indicated in a comment.  When I see
deprecated or old hack or similar terms in code it takes some
archaeology to figure out when it was added and when it could be
removed.   It would be nice to help the future reader a bit.

-- 
Eitan Adler
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-23 Thread Darren Pilgrim 
Thank you for this, but if I may make one suggestion: don't combine all 
the security report settings--keep both daily_* and weekly_*.  This 
makes possible running some security tasks on a daily basis and others 
on a weekly basis.  For example, daily pkg/portaudit checks, but weekly 
filesystem scans.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: weekly periodic security status

2013-08-23 Thread Royce Williams 
On Fri, Aug 23, 2013 at 10:44 AM, Darren Pilgrim 
list_free...@bluerosetech.com wrote:

 Thank you for this, but if I may make one suggestion: don't combine all
 the security report settings--keep both daily_* and weekly_*.  This makes
 possible running some security tasks on a daily basis and others on a
 weekly basis.  For example, daily pkg/portaudit checks, but weekly
 filesystem scans.


Agreed.  I welcome and would use the weekly option at this level of
granularity, but would like to retain daily for many checks, and so would
not use weekly if was an all-or-nothing option.

Royce
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

weekly periodic security status

2013-08-22 Thread Jeremie Le Hen 
Hi,

I plan to commit the attached patch.  This allows the turn the daily
security checks into weekly checks.  You do this by adding the following
to periodic.conf(5):

daily_status_security_enable=NO
weekly_status_security_enable=YES

All other $daily_status_security_whatever variables will be renamed to
$security_status_whatever.  The old variable name is supported but
prints a warning.

The idea is that for many personal servers, whether it is used as a NAS
or for developement, you may not want to run I/O-expensive find(1) jobs
every day, but you don't want to disable entirely because there's a
little voice that tells you it's bad.

Well, whatever, if you have any concerns, objections or comments, please
speak now :).

Note that once I will have committed this, I will make another commit to
the manpage so as to move the security options into their own section,
out of the daily section.  But it is clearer for review that way I
think.

The patch is also available here:
http://people.freebsd.org/~jlh/weekly_status_security.diff

Cheers,
-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
Index: etc/defaults/periodic.conf
===
--- etc/defaults/periodic.conf	(revision 254638)
+++ etc/defaults/periodic.conf	(working copy)
@@ -164,58 +164,58 @@ daily_local=/etc/daily.local# Local scripts
 
 # These options are used by the security periodic(8) scripts spawned in
 # 450.status-security above.
-daily_status_security_inline=NO			# Run inline ?
-daily_status_security_output=root			# user or /file
-daily_status_security_noamd=NO			# Don't check amd mounts
-daily_status_security_logdir=/var/log			# Directory for logs
-daily_status_security_diff_flags=-b -u		# flags for diff output
+security_status_inline=NO			# Run inline ?
+security_status_output=root			# user or /file
+security_status_noamd=NO			# Don't check amd mounts
+security_status_logdir=/var/log			# Directory for logs
+security_status_diff_flags=-b -u		# flags for diff output
 
 # 100.chksetuid
-daily_status_security_chksetuid_enable=YES
+security_status_chksetuid_enable=YES
 
 # 110.neggrpperm
-daily_status_security_neggrpperm_enable=YES
+security_status_neggrpperm_enable=YES
 
 # 200.chkmounts
-daily_status_security_chkmounts_enable=YES
-#daily_status_security_chkmounts_ignore=^amd:		# Don't check matching
+security_status_chkmounts_enable=YES
+#security_status_chkmounts_ignore=^amd:		# Don't check matching
 			# FS types
 
 # 300.chkuid0
-daily_status_security_chkuid0_enable=YES
+security_status_chkuid0_enable=YES
 
 # 400.passwdless
-daily_status_security_passwdless_enable=YES
+security_status_passwdless_enable=YES
 
 # 410.logincheck
-daily_status_security_logincheck_enable=YES
+security_status_logincheck_enable=YES
 
 # 460.chkportsum
-daily_status_security_chkportsum_enable=NO	# Check ports w/ wrong checksum
+security_status_chkportsum_enable=NO	# Check ports w/ wrong checksum
 
 # 500.ipfwdenied
-daily_status_security_ipfwdenied_enable=YES
+security_status_ipfwdenied_enable=YES
 
 # 510.ipfdenied
-daily_status_security_ipfdenied_enable=YES
+security_status_ipfdenied_enable=YES
 
 # 520.pfdenied
-daily_status_security_pfdenied_enable=YES
+security_status_pfdenied_enable=YES
 
 # 550.ipfwlimit
-daily_status_security_ipfwlimit_enable=YES
+security_status_ipfwlimit_enable=YES
 
 # 610.ipf6denied
-daily_status_security_ipf6denied_enable=YES
+security_status_ipf6denied_enable=YES
 
 # 700.kernelmsg
-daily_status_security_kernelmsg_enable=YES
+security_status_kernelmsg_enable=YES
 
 # 800.loginfail
-daily_status_security_loginfail_enable=YES
+security_status_loginfail_enable=YES
 
 # 900.tcpwrap
-daily_status_security_tcpwrap_enable=YES
+security_status_tcpwrap_enable=YES
 
 
 # Weekly options
@@ -248,6 +248,10 @@ weekly_status_pkg_enable=NO# Find out-of-dat
 pkg_version=pkg_version	# Use this program
 pkg_version_index=/usr/ports/INDEX-10			# Use this index file
 
+# 450.status-security; disabled by defaut because daily checks are enabled
+weekly_status_security_enable=NO			# Security check
+# See Security options above for more options
+
 # 999.local
 weekly_local=/etc/weekly.local			# Local scripts
 
@@ -276,6 +280,16 @@ monthly_local=/etc/monthly.local			# Local scrip
 
 if [ -z ${source_periodic_confs_defined} ]; then
 source_periodic_confs_defined=yes
+	daily_security_var_compat() {
+		local new=$1 old
+
+		old=daily_status_security${#status_security}
+		[ -z $old ]  return
+		echo Warning: Variable \$$old is deprecated, \
+		use \$$new instead. 2
+		eval \$$new=\$old\
+	}
+
 source_periodic_confs() {
 local i sourced_files
 
Index: etc/periodic/security/100.chksetuid
===
--- etc/periodic/security/100.chksetuid	(revision 254638)
+++ etc/periodic/security/100.chksetuid	(working copy)
@@ -39,7 +39,9