Re: Bug#798979: [SECURITY] [DSA 3359-1] virtualbox security update
. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/4.1.7+/updates/dkms/ vboxnetflt.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/4.1.7+/updates/dkms/ vboxpci.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/4.1.7+/updates/dkms/ depmod DKMS: install completed. (Reading database ... 332296 files and directories currently installed.) Preparing to unpack .../virtualbox_5.0.4-dfsg-3_amd64.deb ... Unpacking virtualbox (5.0.4-dfsg-3) over (5.0.4-dfsg-2) ... Processing triggers for systemd (226-2) ... Processing triggers for man-db (2.7.3-1) ... Setting up virtualbox (5.0.4-dfsg-3) ... Setting up virtualbox-qt (5.0.4-dfsg-3) ... Processing triggers for menu (2.1.47) ... Current status: 6 updates [-3]. 22:59 ♒♒♒ ☺ On Fri, 2015-09-18 at 10:17 +, Gianfranco Costamagna wrote: > BTW I'm mostly sure as we specified in a previous email, this problem > is not related to the security > DSA, but with a race condition in an upgrade path handled by apt. > (probably always here, but with systemd it might be occurring more > frequently). > > (it might have happened with a one-line patch, or even with a no > change rebuild) > > > A solution might be to do a > "systemctl stop virtualbox" and check that no "VBoxSVC" is running. > > > (and sorry for the bad experience you had) > > > cheers, > > Gianfranco > -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Re: Bug#794466: Virtualbox might not be suitable for Stretch
On Mon, 2015-08-10 at 07:16 +, Gianfranco Costamagna wrote: But if the security team can agree up with this release model, then the VBox team could just keep it up-to-date. Yes, otherwise the points remains: 1) leave the oracle with CVEs in stable releases or 2) have an exception from Security Team and/or Release Team or 3) wait and hope Oracle will change the model or make an exception 1) means a disappear of VBox from Testing I'm afraid 2) We will continue to provide security new releases, and fix almost all the CVEs around here (except for one in o-o-stable) 3) this is kind of impossible right now I guess (even if Oracle employees are continuing to try to have it) Does anyone know what Fedora project's stand is on VBox ? From what I've checked so far, Fedora does not ship VBox. But I'm not sure what their reasons are... -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Re: Bug#794466: Virtualbox might not be suitable for Stretch
On Mon, 2015-08-10 at 07:40 +0200, Markus Frosch wrote: I'm not sure how they handle vulnerabilities. But their release strategy is: ESR and Regular releases. Every security fix goes into the next Regular release, and also the ESR release. ESR is supported until the next ESR (31 = 38). So usually the Debian Mozilla team prefers the ESR branch for Debian stable. With VBox, they don't have an ESR model. I guess they don't call it ESR or long term support, but as Gianfranco pointed out, they seem to support a lot of major releases currently. The main problem is here, do we want to use their upstream releases? In lack of a proper patch source, the Oracle way... Yes. And I guess this is going to be more of a decision making challenge for the sec team. Debian Security Team: These are what we have currently in Debian: oldstable: 4.1.18 stable: 4.3.18 testing: 4.3.30 So, to keep the stable version secure in the Oracle way, we'll need to push it to 4.3.30. Please look at: https://www.virtualbox.org/wiki/Changelog-4.3 for the 4.3.x changelog. Similarly, 4.1.x here: https://www.virtualbox.org/wiki/Changelog-4.1 The good thing is that Oracle declares these as Maintenance release. So usual sane practise for them too, should be, to only update it with Security Fixes. Though this has not been the case in the past. There have been regressions. But if the security team can agree up with this release model, then the VBox team could just keep it up-to-date. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Re: Fwd: Problem with multiple root-users (UID=0)
Hello Mike,
Yes, That'd be debian-security@lists.debian.org, Cced with this email.
Ritesh
On 11/16/2011 11:15 AM, Mike Christie wrote:
Hey Ritesh,
Does Debian have some sort of security list? I asked some red hat people
and they thought removing the check for root and just checking for
UID=0 would be ok. They were not 100% sure though since we could not
figure out why the original maintainers check explicitly for root. So I
have been checking with distro people to make sure it is ok with their
security people.
Thanks
Mike
Original Message
Subject: Problem with multiple root-users (UID=0)
Date: Mon, 7 Nov 2011 11:37:29 -0800 (PST)
From: Thomas Weichert tho...@weichert-web.de
Reply-To: open-is...@googlegroups.com
To: open-iscsi open-is...@googlegroups.com
Hi,
in the last few days I encountered a problem on my SLES 11.1 Linux
with the open-iscsi package in version 2.0-871 respectively 0.872. I
investigated the problem and found out that in my system there are two
root users with uid = 0 (sadly, this is required). Therefore I digged
deeper and found out that the problem most probably lies in the two
code snippets where root is defnied explicitely. Those are usr/
mgmt_ipc.c around line 549 with:
if (!mgmt_peeruser(fd, user) || strncmp(user, root, PEERUSER_MAX)) {
err = MGMT_IPC_ERR_ACCESS;
goto err;
}
as well as usr/statics.c around line 7:
static struct passwd root_pw = {
.pw_name = root,
}
When the Linux command `whoami` returns something different than
root, open-iscsi will not work.
As far as I understand the issue, the function call to mgmt_peeruser()
in mgmt_ipc.c sets the variable user to the currently logged in user
name and then it is compared to root. If my root-user is named
differently, the strncmp function fails of course. I did not
investigate the code in statics.c further, whether it plays a role or
not, since a change to mgmt_ipc.c solves my problem.
Is there a chance to fix this issue just by checking if the user has
sufficient rights, e.g. has uid=0, or is there any special reason for
demanding a user named root?
Thanks a lot
Thomas
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
signature.asc
Description: OpenPGP digital signature
