[17:35] <sdeziel> `grub-efi-amd64` is apparently getting a security fix but apt seems to be phasing its distribution as on some of my machines it is listed as being "kept back"
[17:35] <sdeziel> is this normal for security fixes to have "phasing" applied?
[17:36] <sdeziel> https://termbin.com/du4o => what I ran
[17:41] <sdeziel> hmm, `apt policy` (https://termbin.com/x2s3) doesn't even show this package as being available through http://security.ubuntu.com/ubuntu/
[18:05] <ahasenack> yo #security, do you recall why in ubuntu we don't share [homes] by default in samba? https://pastebin.ubuntu.com/p/FmkZXNVCqx/
[18:05] <ahasenack> maybe because home was 0755 until recently?
[18:05] <ahasenack> but still, over the network, you would only be able to see the contents of home through samba if you authenticated as the user
[18:06] <ahasenack> that commit was from 2013, for trusty
[18:07] <ahasenack> maybe to avoid clear-text traffic of things like ~/.gnupg, ~/.ssh and such?
[18:08] <ahasenack> back then it was clear text, I'm almost sure
[18:08] <mdeslaur> ahasenack: I can't remember exactly, but I still don't think it's a good idea to enable that by default...especially since it would allow access to home directories with simple passwords?
[18:08] <sdeziel> ahasenack: nowadays those files are denied access by smbd's Apparmor policy
[18:09]  * sdeziel wonders if smbd's AA policy defaults to enable
[18:09] <ahasenack> sdeziel: you mean the samba apaprmor? Sorry, not there by default
[18:09] <sdeziel> ah, sorry then
[18:09] <ahasenack> hint: I'll try to get it in good shape for lunar lobster
[18:10] <ahasenack> mdeslaur: first you would have to create the samba user matching your linux user (smbpasswd -a <user>)
[18:10] <ahasenack> and that password can be anything, yes
[18:10] <mdeslaur> hrm
[18:10] <mdeslaur> I thought we were using something that did that automatically
[18:10] <ahasenack> so uncommenting [homes] won't export it by default
[18:11] <mdeslaur> didn't we have pam integration or something?
[18:11] <ahasenack> I mean, it will be visible, but there will be no set of credentials to access it
[18:11] <ahasenack> there are pam account restrictions that samba should follow, yes
[18:12] <ahasenack> and "unix password sync", and some horrible expect-like "chat" setting, if you use the network RPC calls to change a user's password
[18:12] <ahasenack> but the tdb file with the samba user passwords is born empty
[18:13] <ahasenack> I can try some of those remotely, see if they do anything nowadays, with a default config
[18:13] <sdeziel> ahasenack: I was even more wrong, the smbd profile doesn't even include the `<abstractions/private-files>` I think it did :/
[18:13] <ahasenack> I'll take note of that
[18:13] <ahasenack> oh, there is a lot of stuff in there
[18:15] <mdeslaur> I'd have to trace back to when we did the change and try and find the uds discussion about it
[18:15] <ahasenack> the changelog has no bug number, too bad
[18:16] <ahasenack> it was done by zulcss
[18:16] <ahasenack> (Chuck SHort)
[18:16] <sdeziel> actually, you need the -strict version (`<abstractions/private-files-strict>`) to block `~/.ssh/` and `/.gnupg/`
[18:16] <ahasenack> in 2:4.0.10+dfsg-4ubuntu1
[18:17] <ahasenack> here: https://git.launchpad.net/ubuntu/+source/samba/commit/?h=import/2%254.0.10%2bdfsg-4ubuntu1&id=16a3ec29185c83d7a4d9a5c59cd680f9a406bc8a
[18:17] -ubottu:#ubuntu-security- Commit 16a3ec2 in ubuntu/+source/samba "2:4.0.10+dfsg-4ubuntu1 (patches unapplied) import/2%4.0.10+dfsg-4ubuntu1"
[18:19] <mdeslaur> I have a feeling the change is older than that, he just dropped the history there
[18:19]  * mdeslaur looks
[18:21] <mdeslaur> samba (3.0.22-1ubuntu3) dapper; urgency=low
[18:21] <mdeslaur>   * Config file changes only in this upload; no destabilising code changes.
[18:21] <mdeslaur>   * Comment out the default [homes] shares and add more verbose comments to
[18:21] <mdeslaur>     explain what they do and how they work (closes: launchpad.net/27608)
[18:21] <mdeslaur> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/27608
[18:21] -ubottu:#ubuntu-security- Launchpad bug 27608 in samba (Ubuntu) "Entire home dir is shared within another in samba!" [Medium, Fix Released]
[18:22] <mdeslaur> ahasenack: I think I remember now....gnome directory sharing used samba, so as soon as you right clicked on a directory and shared it, samba would share your home directory without you knowing
[18:23] <mdeslaur> yeah, that's why we disabled that
[18:27] <ahasenack> ah, good find about the older change
[18:27] <ahasenack> that gnome share thing still exists, but it requires you to run "sudo smbpasswd -a <yourname>" nowadays, or last I checked
[18:27] <ahasenack> I think back then in 3.0.x days, samba was using plain text passwords still perhaps?
[18:28] <ahasenack> remember one had to change a registry setting in windows to get it to use plain text passwords and then work with samba?
[18:28] <ahasenack> this would be one way to get it to work without the smbpasswd command, samba could then just check /etc/shadow as any other app (get the clear text password from the user, hash it, compare)
[18:31] <mdeslaur> hrm, I think it would ask you to set a password
[18:31] <mdeslaur> I'd have to try it
[18:31] <mdeslaur> one sec
[18:32] <mdeslaur> I do know upstream gnome switched to clear text webdav at some point, but we kept samba integration
[18:34] <ahasenack> ugh, no attachments to that bug, just links to external sites, links that are dead now of course
[18:35] <ahasenack> ah
[18:35] <ahasenack> the guy shared a directory within his home, and gave the *share* the name of his user
[18:35] <ahasenack> which of course triggers [homes] 
[18:36] <mdeslaur> wouldn't sharing any other directory do the same thing, as soon as you set the password?
[18:36] <ahasenack> no, the username is special
[18:36] <ahasenack> if you access //server/<your-linux-user>, it will clone the [homes] share and create a share called [your-linux-user]
[18:37] <ahasenack> but he had a share [your-linux-user] already created, for another directory
[18:37] <ahasenack> via gnome
[18:37] <ahasenack> I don't know if this is undefined behavior (two shares with the same name pointing at different paths)
[18:37] <ahasenack> but it's something I can try
[18:37] <mdeslaur> well, if [homes] is configured, isn't your home directory shared as soon as you create a password?
[18:38] <ahasenack> about the cloning of [homes], I mean samba will create [your-linux-user] with a path of ~your-linux-user (i.e., your-linux-user's $HOME)
[18:41] <mdeslaur> how the heck is gnome creating the share...I can see it but I have no idea where it's telling samba to add it
[18:41] <ahasenack> if [homes] is configured, any access to //server/valid-linux-user will create [valid-linux-user] with the settings from [homes]. If [homes] requires a password, then you will need a password. The extra nice setting to have is "valid users = %S", so the only valid user for that share will be the actual home owner
[18:41] <ahasenack> gnome is using a dynamic share mechanism, just a sec, I even fixed a bug in that for jammy or kinetic
[18:42] <ahasenack> "usershare" is its name
[18:42] <ahasenack> there is a sambashare unix group
[18:43] <ahasenack> search for "USERSHARES" in man smb.conf
[18:46] <mdeslaur> ah, it's in /var/lib/samba/usershares huh
[18:51] <ahasenack_> it's nautilus-share: https://bugs.launchpad.net/ubuntu/+source/nautilus-share/+bug/1967245
[18:51] -ubottu:#ubuntu-security- Launchpad bug 1967245 in nautilus-share (Ubuntu) "'net usershare' returned error 255 on jammy-desktop-amd64" [High, Fix Released]
[18:51] <mdeslaur> ah yes, that's it
[18:57] <mdeslaur> ahasenack: perhaps we can talk about this next week at the sprint
[18:58] <ahasenack> I won't be there I'm afraid (phisically), but I'll attend remotely, time shifting
[18:58] <mdeslaur> ah, I see
[18:58] <ahasenack> I'm revisiting this because it's one delta we have with debian
[18:59] <mdeslaur> I'd like amurray to chime in on this...I still think it's odd to share everyone's directories by default, it's kind of unexpected
[19:00] <ahasenack> it's a valid point
[19:20] <ahasenack> well, the good news is that nautilus-share (well, the "net usershare" command from samba, which creates these shares) does not allow you to create a share that matches a local user
[19:20] <ahasenack> """'net usershare' returned error 255: net usershare add: share name debian is already a valid system user name"""
[19:21] <ahasenack> I have a local debian user, and opted to share my ~/Videos directory, but gave the share the name "debian"
[19:21] <ahasenack> and I don't even have [homes] enabled
[19:21] <ahasenack> so maybe the concerns of that original bug are gone, but it's still a valid point of discussion, if we should share [homes] by default or not
[19:22] <ahasenack> for now, I'll keep it as is, of course (not sharing)
[19:22] <ahasenack> it's a small delta with debian anyway
[19:28] <ahasenack> this usershare thing is wonky