Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: getting the running patch level
2 views
Skip to first unread message
Peter Jeremy
Aug 20, 2012, 5:04:47 PM8/20/12
to
On 2012-Aug-19 16:46:37 +0200, Paul Schenkeveld <fre...@psconsult.nl> wrote:
> - 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.
I'm not sure what detail you intend here. One line per installworld
or similar sounds OK. One line per file seems excessive - especially
if you intend to retain history ("df -ki" suggests that a base install
is around 30,000 files).
> - 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
How do you envisage this tool determining that /usr/sbin/foo is at
8.3-RELEASE-p2 and this is incorrect when userland is at (eg)
8.3-RELEASE-p4? Note that updating your system from 8.3-RELEASE-p2 to
8.3-RELEASE-p4 may not change /usr/sbin/foo and therefore it will
remain untouched.
>The /etc/issue file mentioned several times in this thread is like motd
>but intended to be shown before a login prompt. This works for console
>logins (getty) but not for remote logins.
SSH includes provision for displaying information prior to login - see
the "Banner" option in sshd_config. Note that this is most definitely
the wrong place to include system version details.
--
Peter Jeremy
> - 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.
I'm not sure what detail you intend here. One line per installworld
or similar sounds OK. One line per file seems excessive - especially
if you intend to retain history ("df -ki" suggests that a base install
is around 30,000 files).
> - 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
How do you envisage this tool determining that /usr/sbin/foo is at
8.3-RELEASE-p2 and this is incorrect when userland is at (eg)
8.3-RELEASE-p4? Note that updating your system from 8.3-RELEASE-p2 to
8.3-RELEASE-p4 may not change /usr/sbin/foo and therefore it will
remain untouched.
>The /etc/issue file mentioned several times in this thread is like motd
>but intended to be shown before a login prompt. This works for console
>logins (getty) but not for remote logins.
SSH includes provision for displaying information prior to login - see
the "Banner" option in sshd_config. Note that this is most definitely
the wrong place to include system version details.
--
Peter Jeremy
Roger Marquis
Aug 21, 2012, 11:49:32 AM8/21/12
to
Jilles Tjoelker wrote:
> I think the idea of having 'make installworld' create something is good,
> but we should not hard-code policy by writing the information into a
> file that may be shown to unauthenticated users (such as by getty).
>
> A new file with a name=value format somewhat like /etc/lsb-release on
> Linux seems more appropriate. If the admin wants /etc/issue,
> /etc/rc.d/motd can create it.
Automatically updating /etc/issue (or /etc/issue.net, but not issue.*
should that be adopted from other OS) has security implications due to
potentially unintended information disclosure.
WRT writing a new file, something like /etc/bsd-release would be a good
choice following the principle of least surprise. Mergemaster can and
should ignore it (and motd, issue, ...).
Strict adherence to the KIS principle, however, would only write this
information to the first line of the motd, after the kernel info.
Simon Nielsen wrote:
> A simple approach would be to just append -uX to the uname string, but I'm
> not really sure if I like that... To ilustrate, if for a 9.0 system, where
> kernel is patch 3 userland is patch 5, we would show FreeBSD
> 9.0-RELEASE-p3-u5. The nice thing is that we don't try to be clever and
> therefor are less likely to get it wrong.
There's not a good way to report on every userland (lib/binary) file but
a simple find and/or checksum (a la integrit) could indicate whether
anything had been updated since the last installworld. That could be
noted by appending a simple "-modified" to whatever uname prints for the
userland version. Attempting to do more than that, IMO, would have a
negative ROI.
IMO,
Roger Marquis
_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"
> I think the idea of having 'make installworld' create something is good,
> but we should not hard-code policy by writing the information into a
> file that may be shown to unauthenticated users (such as by getty).
>
> A new file with a name=value format somewhat like /etc/lsb-release on
> Linux seems more appropriate. If the admin wants /etc/issue,
> /etc/rc.d/motd can create it.
Automatically updating /etc/issue (or /etc/issue.net, but not issue.*
should that be adopted from other OS) has security implications due to
potentially unintended information disclosure.
WRT writing a new file, something like /etc/bsd-release would be a good
choice following the principle of least surprise. Mergemaster can and
should ignore it (and motd, issue, ...).
Strict adherence to the KIS principle, however, would only write this
information to the first line of the motd, after the kernel info.
Simon Nielsen wrote:
> A simple approach would be to just append -uX to the uname string, but I'm
> not really sure if I like that... To ilustrate, if for a 9.0 system, where
> kernel is patch 3 userland is patch 5, we would show FreeBSD
> 9.0-RELEASE-p3-u5. The nice thing is that we don't try to be clever and
> therefor are less likely to get it wrong.
There's not a good way to report on every userland (lib/binary) file but
a simple find and/or checksum (a la integrit) could indicate whether
anything had been updated since the last installworld. That could be
noted by appending a simple "-modified" to whatever uname prints for the
userland version. Attempting to do more than that, IMO, would have a
negative ROI.
IMO,
Roger Marquis
_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"
Adrian Penisoara
Aug 22, 2012, 6:44:07 AM8/22/12
to
Hello,
On Tue, Aug 21, 2012 at 6:49 PM, Roger Marquis <mar...@roble.com> wrote:
> Jilles Tjoelker wrote:
[...]
makes me think about /var/db/freebsd-update/tag) the current release
version details of the system (not only the kernel, but the whole
installed system). This seems to be a popular choice among Linux
distributions and thus ISV's should feel comfortable with the
approach.
Mergemaster and/or other updating mechanisms should update the file
to reflect the reality after upgrades/updates.
Now the format of the file would be also debatable: other vendors
releasing derivative works from the main FreeBSD source tree (like
FreeNAS, PC-BSD, etc.) will want to leave some marks as well. Should
we retain only the vendor's release tag or should we have a multiple
entries (for the original FreeBSD version and the vendor) ? Should we
even think about multiple ${vendor}-release files or just bsd-release
?
Thanks for your time,
Adrian Penisoara
EntepriseBSD
On Tue, Aug 21, 2012 at 6:49 PM, Roger Marquis <mar...@roble.com> wrote:
> Jilles Tjoelker wrote:
[...]
>
> WRT writing a new file, something like /etc/bsd-release would be a good
> choice following the principle of least surprise. Mergemaster can and
> should ignore it (and motd, issue, ...).
>
I support the idea of using an /etc/*-release file to tag (and this
> WRT writing a new file, something like /etc/bsd-release would be a good
> choice following the principle of least surprise. Mergemaster can and
> should ignore it (and motd, issue, ...).
>
makes me think about /var/db/freebsd-update/tag) the current release
version details of the system (not only the kernel, but the whole
installed system). This seems to be a popular choice among Linux
distributions and thus ISV's should feel comfortable with the
approach.
Mergemaster and/or other updating mechanisms should update the file
to reflect the reality after upgrades/updates.
Now the format of the file would be also debatable: other vendors
releasing derivative works from the main FreeBSD source tree (like
FreeNAS, PC-BSD, etc.) will want to leave some marks as well. Should
we retain only the vendor's release tag or should we have a multiple
entries (for the original FreeBSD version and the vendor) ? Should we
even think about multiple ${vendor}-release files or just bsd-release
?
Thanks for your time,
Adrian Penisoara
EntepriseBSD
olli hauer
Aug 22, 2012, 7:40:37 AM8/22/12
to
On 2012-08-22 12:44, Adrian Penisoara wrote:
> Hello,
>
> On Tue, Aug 21, 2012 at 6:49 PM, Roger Marquis <mar...@roble.com> wrote:
>> Jilles Tjoelker wrote:
> [...]
>>
>> WRT writing a new file, something like /etc/bsd-release would be a good
>> choice following the principle of least surprise. Mergemaster can and
>> should ignore it (and motd, issue, ...).
>>
>
> I support the idea of using an /etc/*-release file to tag (and this
> makes me think about /var/db/freebsd-update/tag) the current release
> version details of the system (not only the kernel, but the whole
> installed system). This seems to be a popular choice among Linux
> distributions and thus ISV's should feel comfortable with the
> approach.
>
> Mergemaster and/or other updating mechanisms should update the file
> to reflect the reality after upgrades/updates.
>
> Now the format of the file would be also debatable: other vendors
> releasing derivative works from the main FreeBSD source tree (like
> FreeNAS, PC-BSD, etc.) will want to leave some marks as well. Should
> we retain only the vendor's release tag or should we have a multiple
> entries (for the original FreeBSD version and the vendor) ? Should we
> even think about multiple ${vendor}-release files or just bsd-release
> ?
In case a new file will be used, I suggest using the cpe framework,
> Hello,
>
> On Tue, Aug 21, 2012 at 6:49 PM, Roger Marquis <mar...@roble.com> wrote:
>> Jilles Tjoelker wrote:
> [...]
>>
>> WRT writing a new file, something like /etc/bsd-release would be a good
>> choice following the principle of least surprise. Mergemaster can and
>> should ignore it (and motd, issue, ...).
>>
>
> I support the idea of using an /etc/*-release file to tag (and this
> makes me think about /var/db/freebsd-update/tag) the current release
> version details of the system (not only the kernel, but the whole
> installed system). This seems to be a popular choice among Linux
> distributions and thus ISV's should feel comfortable with the
> approach.
>
> Mergemaster and/or other updating mechanisms should update the file
> to reflect the reality after upgrades/updates.
>
> Now the format of the file would be also debatable: other vendors
> releasing derivative works from the main FreeBSD source tree (like
> FreeNAS, PC-BSD, etc.) will want to leave some marks as well. Should
> we retain only the vendor's release tag or should we have a multiple
> entries (for the original FreeBSD version and the vendor) ? Should we
> even think about multiple ${vendor}-release files or just bsd-release
> ?
see http://cpe.mitre.org/specification/
Using a standard framework makes it easier to write platform
independent tools for example in visualization environments.
sample /etc/system-release-cpe entry
cpe:/o:freebsd:8.3:ga:x64 ...
--
Regards,
olli
olli hauer
Aug 22, 2012, 7:49:44 AM8/22/12
to
>
> sample /etc/system-release-cpe entry
> cpe:/o:freebsd:8.3:ga:x64 ...
Thomas
Aug 24, 2012, 8:52:57 AM8/24/12
to
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:
> 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
> 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?
Regards,
Thomas
> 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
> - 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.
>
> 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
> - 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
>
> 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?
Regards,
Thomas
Simon L. B. Nielsen
Aug 24, 2012, 11:49:22 AM8/24/12
to
which we will hopefully come up with?
--
Simon L. B. Nielsen
Thomas
Aug 24, 2012, 1:28:47 PM8/24/12
to
net-snmp in ports.
FreeBSD-MIB for bsnmpd(1) uses uname(3) for freeBSDVersion
OBJECT-IDENTITY but according to the comments in FreeBSD-MIB.txt it can
be overwritten.
Not sure what net-snmp is using.
Regards,
Thomas
0 new messages