Re: getting the running patch level
On 09/08/2012 23:13, Glen Barber wrote: > On Thu, Aug 09, 2012 at 03:31:25PM -0600, Brett Glass wrote: >> > I realize that sysinstall is deprecated in favor of the new installer, but >> > the new installer doesn't have the ability to install binary packages. >> > Until and unless there's a convenient menu-based installer for binary >> > packages, would it be possible to fix this glitch? > There is always pkgng, granted it is not menu-driven. No reason pkgng couldn't be wrapped in some sort of menuing system. In fact, it's probably quite a lot easier than doing the same sort of thing with the old pkg_tools. Also, pkgdb functionality is expressed through libpkg.so.1, meaning that hooking it up to a different front-end should be a small matter of programming. There is already a Ruby interface available, and other languages are being worked on. The libpkg API is still subject to incompatible changes at this stage of development: that won't be settled for quite some time yet. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
RE: getting the running patch level
So as far I understand, if the kernel is not updated by the update process, it is not possible to get via "uname" the currently patch level. I also read about put some syscall to return from the kernel the current patch level, but still this solution is "bound" to the kernel modification, which could be not in all cases; in my opinion, why should the kernel keep track of user space packages ? in other word, if freebsd-update change a ssh package (just an example) why this operation should have side effects with the kernel ? But this is just my opinion. I also think this task (keeping track of patch level) should better related to the command freebsd-update itself, should not ? could the update system (that include freebsd-update) keep track of what is the current system patching state ? and why not all previous package updates ? still these are my ideas... Roberto On Thu, August 9, 2012 18:05, Cedric GROSS wrote: > Hello Roberto, > > In fact "uname -a" report patch level BUT if you update your system by > freebsd-update, patch level could be an old one. > As discuss here http://forums.freebsd.org/archive/index.php/t-20154.html > > Regards > Cedric ___ 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"
Re: [Full-disclosure] nvidia linux binary driver priv escalation exploit
On Wed, Aug 8, 2012 at 1:38 PM, Wesley Shields wrote: > On Wed, Aug 08, 2012 at 10:34:06AM +, Alexey Dokuchaev wrote: >> On Mon, Aug 06, 2012 at 01:49:50PM +0200, Rainer Hurling wrote: >> > Am 06.08.2012 10:03 (UTC+1) schrieb Doug Barton: >> > >On 08/01/2012 05:09, Oliver Pinter wrote: >> > >>I found this today on FD: >> > >> >> > >>http://seclists.org/fulldisclosure/2012/Aug/4 >> > > >> > >Apparently this affects us as well. Any news? >> > >> > Thanks for the info. I had been not aware of it before. >> > >> > NVidia has released a driver version 304.32 for FreeBSD i386 and amd64, >> > which should remedy these security issues. >> >> Luckily, they've released version 295.71 which is on Long Lived Branch. I >> will update the port shortly. > > Thank you! > >> VuXML entry will have to follow separately, as it is unclear whether new CVE >> number will be assigned or not. > > You can do the VuXML without a CVE for now and update it when/if one is > assigned. Eh, why wouldn't a CVE name not be assigned? If none is we should ask MITRE to assign one, but it would surprise me if NVIDIA or a Linux vendor hasn't done this already. -- 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"
Re: getting the running patch level
On Fri, Aug 10, 2012 at 1:06 PM, Roberto wrote: > > So as far I understand, if the kernel is not updated by the update process, it > is not possible to get via "uname" the currently patch level. Correct. This has been discussed a number of time, but there are no nice and simple solution. There is a simple solution if we just update the kernel always, but that's a hack IMO. While the problem seems rather simple, there are many corner cases making it hard to solve. It should be solved so people can get this information, personally I just haven't had the time to work on it. -- 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"
Re: [Full-disclosure] nvidia linux binary driver priv escalation exploit
On 08/10/2012 09:35 PM, Simon L. B. Nielsen wrote: [..] > On 08/01/2012 05:09, Oliver Pinter wrote: >> I found this today on FD: >> >> http://seclists.org/fulldisclosure/2012/Aug/4 [..] > Eh, why wouldn't a CVE name not be assigned? If none is we should ask > MITRE to assign one, but it would surprise me if NVIDIA or a Linux > vendor hasn't done this already. This is from oss-security: Original Message Subject: Re: [oss-security] CVE Request: NVidia Linux driver Date: Wed, 8 Aug 2012 18:46:34 -0400 (EDT) From: cve-ass...@mitre.org Reply-To: oss-secur...@lists.openwall.com To: marc.deslauri...@canonical.com CC: cve-ass...@mitre.org, oss-secur...@lists.openwall.com, secur...@ubuntu.com > http://seclists.org/fulldisclosure/2012/Aug/4 > http://nvidia.custhelp.com/app/answers/detail/a_id/3140 Use CVE-2012-4225. -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] ___ 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"
Re: getting the running patch level
On Aug 10, 2012, at 09:40 , Simon L. B. Nielsen wrote: > On Fri, Aug 10, 2012 at 1:06 PM, Roberto wrote: >> >> So as far I understand, if the kernel is not updated by the update process, >> it >> is not possible to get via "uname" the currently patch level. > > Correct. > > This has been discussed a number of time, but there are no nice and > simple solution. There is a simple solution if we just update the > kernel always, but that's a hack IMO. > > While the problem seems rather simple, there are many corner cases > making it hard to solve. It should be solved so people can get this > information, personally I just haven't had the time to work on it. Split off a version.ko and update that with each patch? -- Chris BeHanna chris@behanna.org___ 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"
Re: getting the running patch level
On 08/10/2012 11:55 PM, Chris BeHanna wrote: > Split off a version.ko and update that with each patch? There is often no need to reboot the machine unless the kernel is affected (just restart the affected daemons). Thus the information would not necessarily match the userland status. The userland and kernel versions need to be kept separate because they may not match. I am often struggling to remember if I updated some machine already or not. I now need to compare the time stamps of newvers.sh and installed binaries to find out. IMHO a sensible approach would be something like what most Linux distros do: Have some file in a standard location and put the information there by generating that file from newvers.sh during make buildworld / installworld". Having it only in the source tree is not sufficient as not every machine has the source tree installed. On LSB compliant Linux distributions the proper way to find this out is the lsb_release command. On many Linux distributions there is also a /etc/DISTRONAME-release file which can be checked (for example /etc/debian-release on Debian and /etc/redhat-release on RHEL and clones). How about /etc/freebsd-release? Or freebsd_release command (shell script) which takes the same flags as lsb_release? -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ 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"
Re: getting the running patch level
On 2012-08-10 16:40, Simon L. B. Nielsen wrote: > On Fri, Aug 10, 2012 at 1:06 PM, Roberto wrote: >> >> So as far I understand, if the kernel is not updated by the update process, >> it >> is not possible to get via "uname" the currently patch level. > > Correct. > > This has been discussed a number of time, but there are no nice and > simple solution. There is a simple solution if we just update the > kernel always, but that's a hack IMO. > > While the problem seems rather simple, there are many corner cases > making it hard to solve. It should be solved so people can get this > information, personally I just haven't had the time to work on it. > Maybe this information can be hold in an additional file, see http://cpe.mitre.org/ There is no guaranty root modifies the cpe files but thats the same for all systems which have cpe already implemented. -- Regards, olli ___ 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"
