On Fri, Aug 24, 2012 at 1:52 PM, Thomas <freebsdli...@bsdunix.ch> wrote:
> On 8/19/12 4:46 PM, Paul Schenkeveld wrote:
>> On Thu, Aug 09, 2012 at 11:44:02AM +0200, Roberto wrote:
>>
>> Having read all responses so far I think a summary of the issue at hand
>> is:
>>
>> - Uname only reports on the kernel version, currently we do not store
>> nor report the userland version.
>>
>> - People would love to know what version of FreeBSD, both kernel and
>> userland, is currently installed/running.
>>
>> - Userland can either be upgraded using make {build,install}world or
>> by freebsd-update, neither logs the version to which userland was
>> updated.
>>
>> - Reporting the userland version is not trivial as not necessarily all
>> parts of userland are of the same version, especially after doing
>> an buildworld/instrallworld with a changed src.conf or make.conf.
>>
>> - We currently reflect the last booted kernel version in /etc/motd.
>>
>> My suggestion would be:
>>
>> - Teach both installworld and freebsd-update to maintain manifest
>> files of what is installed and log that update, place all manifests
>> somewhere under /var/db and the update log in /var/log.
>>
>> - If the above log message is well defined and includes the method
>> by which the update was done, it can be parsed by /etc/rc.d/motd
>> and we could extend the information in /etc/motd to also include
>> information about userland. Something like:
>>
>> <tool> <timestamp> <who> <current-version>
>> portupgrade 2012-08-19T16:26:41 paul 8.3-RELEASE-p4
>> installworld 2012-08-19T16:31:36 paul 8-STABLE-r231558
>>
>> - Having manifests of what's installed, one could check if all files
>> are stil the right version, if older manifests are not discarded
>> when performing an update this could also detect files that were
>> not updated for whatever reason or that were reverted, i.e. by
>> restoring some backup. E.g.:
>>
>> Current userland version: 8.3-RELEASE-p4
>> /usr/sbin/named is at 8.3-RELEASE-p2
>> /usr/bin/openssl is at 8.3-RELEASE
>>
>> - Such a time-consuming check could be run from periodic (weekly or
>> monthly perhapd) and be a valuable tool to warn sysadmins of files
>> not being what they should be.
>>
>> - Adding, in the case of freebsd-update, a signature to the manifest
>> files that can be checked against the signature in the freebsd-update
>> master repository could turn this tool into something of a integrity
>> checking tool.
>>
>
> Sounds good if you have a just a few systems. In a large environment,
> snmp is quite common to collect release information.
>
> AFAIK snmp uses kern.version and kern.osrelease for this.This sysctls
> are read only. Any ideas how this issue can be fixed for
> snmp in a easy way?
Make the snmp daemon not do it that way and support magic new scheme
which we will hopefully come up with?
--
Simon L. B. Nielsen
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
