Re: strawman proposal: homed directories for users
On Thu, Oct 10 2024 at 05:36:25 PM +02:00:00, Lennart Poettering wrote: I wished Fedora would focus more on making Measured Boot by default a thing (other distros are working towards that, for example SUSE has been investing in that), but Fedora is not precisely leading in this effort right now. At this point, I think the main obstacle is there are not really any humans working to make it happen. I think we have interest and willingness, but this isn't a small project and it won't develop itself. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Fri, 2024-10-11 at 09:43 +0200, Lennart Poettering wrote: > On Do, 10.10.24 17:22, Simo Sorce (s...@redhat.com) wrote: > > > On Thu, 2024-10-10 at 17:29 +0200, Lennart Poettering wrote: > > > On Mi, 09.10.24 11:12, Simo Sorce (s...@redhat.com) wrote: > > > > > > > > > > > > > This was again a reference to the fact that IPA folks aren't willing > > > to restrict their allocations to some reasonable UID range, as > > > mentoined elsewhere in this thread. > > > > > > > Can you stop with this please? > > This is absolutely not true is starting to become really annoying and > > tiresome, let's please not do that. > > > > It has been explained to you by me (and in person years ago) and others > > multiple times that FreeIPA has a fixed range it picks from, but to > > allow *multiple* domains to interoperate it picks a subrange from that > > big one fixed range, which is high up in the "millions* (I forget the > > exact range but I think 1M-2M). > > Stephen said in this very thread the IPA range is 10K…2010K. > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IO33GOYAHHTRL7LIGXW5WJQNIUYW2WND/ > > So what is it now? > > The difference is pretty relevant, because 10K means 16bit range, and > coverage of the special Linux UIDs 65535, 65534. > > > As an example this is my personal domain user which I installed ages > > ago and has this record: > > > > $ getent passwd simo > > simo:*:164903:164903:Simo Sorce:/home/simo:/bin/bash > > > > As you can see there is no conflict with any reserved ID, please get > > your facts straight. > > Well, you guys are contradicting each other! > > Can you please tell me the accurate fixed range that IPA allocates > from? I heard various things now: > >10K…2010K (Stephen) >1M…2M (you, above) >200K…2G (somewhere in the IPA docs) > > What is it now? Alexander Bokovoy gave you a document more than once over the years. The total range IPA picks from by default is 200K-2G, from which an IPA domain picks a random 200K range by default and sticks to it for the life of the domain. I just said in the millions, because that is generally what happens, I wasn't trying to be exact, because it doesn't matter, it is clearly outside of the danger zone, and for the purpose of the discussion it didn't matter to be exact. > > if 1M…2M is right I'd be quite happy actually, that's a managable > range, I'd be happy make systemd respect that. Alas, I think it's not > actually accurate, is it? > > 10K…2010K would be highly problematic, because it overlaps with said > spcial Linux UIDs, and is 16bit and so on. > > 200K…2G would be problematic too, for example it conflicts with where > local subuid/subgid allocates from (524288…60010). Local subuid/subgid things came a decade+ after FreeIPA had established ranges, and as you said it is a bad idea to use subuids, I agree with that, so I do not care that we conflict. Look a 32bit UID range is just ridiculous, it *cannot* work for everybody, so conflicts will just happens if you take many unmanaged machines in aggregate. In domains that need conflict free IDs administrator have to be involved and have to make reasonable choices and carve out pieces where there is a conflict. This is an unsolvable problem with the way the Linux kernel manages IDs, The solution exist in the industry and it is what Microsoft calls SIDs, if we had that we would be reserving special domain SID spaces for various special purposes and leave others for actual real user domain IDs. Unfortunately nobody wants to introduce such a concept in the Linux kernel, so we'll live with conflicts for the forseable future. Simo. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Do, 10.10.24 17:22, Simo Sorce (s...@redhat.com) wrote: > On Thu, 2024-10-10 at 17:29 +0200, Lennart Poettering wrote: > > On Mi, 09.10.24 11:12, Simo Sorce (s...@redhat.com) wrote: > > > > > > > > > This was again a reference to the fact that IPA folks aren't willing > > to restrict their allocations to some reasonable UID range, as > > mentoined elsewhere in this thread. > > > > Can you stop with this please? > This is absolutely not true is starting to become really annoying and > tiresome, let's please not do that. > > It has been explained to you by me (and in person years ago) and others > multiple times that FreeIPA has a fixed range it picks from, but to > allow *multiple* domains to interoperate it picks a subrange from that > big one fixed range, which is high up in the "millions* (I forget the > exact range but I think 1M-2M). Stephen said in this very thread the IPA range is 10K…2010K. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IO33GOYAHHTRL7LIGXW5WJQNIUYW2WND/ So what is it now? The difference is pretty relevant, because 10K means 16bit range, and coverage of the special Linux UIDs 65535, 65534. > As an example this is my personal domain user which I installed ages > ago and has this record: > > $ getent passwd simo > simo:*:164903:164903:Simo Sorce:/home/simo:/bin/bash > > As you can see there is no conflict with any reserved ID, please get > your facts straight. Well, you guys are contradicting each other! Can you please tell me the accurate fixed range that IPA allocates from? I heard various things now: 10K…2010K (Stephen) 1M…2M (you, above) 200K…2G (somewhere in the IPA docs) What is it now? if 1M…2M is right I'd be quite happy actually, that's a managable range, I'd be happy make systemd respect that. Alas, I think it's not actually accurate, is it? 10K…2010K would be highly problematic, because it overlaps with said spcial Linux UIDs, and is 16bit and so on. 200K…2G would be problematic too, for example it conflicts with where local subuid/subgid allocates from (524288…60010). Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Чцв, 10 кас 2024, Stephen Gallagher wrote: On Thu, Oct 10, 2024 at 5:23 PM Simo Sorce wrote: On Thu, 2024-10-10 at 17:29 +0200, Lennart Poettering wrote: > On Mi, 09.10.24 11:12, Simo Sorce (s...@redhat.com) wrote: > > > > > This was again a reference to the fact that IPA folks aren't willing > to restrict their allocations to some reasonable UID range, as > mentoined elsewhere in this thread. > Can you stop with this please? This is absolutely not true is starting to become really annoying and tiresome, let's please not do that. It has been explained to you by me (and in person years ago) and others multiple times that FreeIPA has a fixed range it picks from, but to allow *multiple* domains to interoperate it picks a subrange from that big one fixed range, which is high up in the "millions* (I forget the exact range but I think 1M-2M). As an example this is my personal domain user which I installed ages ago and has this record: $ getent passwd simo simo:*:164903:164903:Simo Sorce:/home/simo:/bin/bash As you can see there is no conflict with any reserved ID, please get your facts straight. Now clearly older Unixes are dead, and NFS has finally come out of the stone age and should be able to handle 32 bit ids everywhere, so there is less need to allocate in a low range, but UIDs in long lived organizations are really hard to change. At RH my Corporate uid is in the low range for historical reasons (there have been at least two migration through NIS and then LDAP servers and finally IPA since I joined a couple of eons ago), and IPA serves it and it is fine. Just to be clear, IPA came out a more than a decade before systemd started looking into any of this, and it was a more than decade after Samba had already dealt with UID mapping in AD domains. Ranges are always local and it is unlikely a system will need to use two competing allocation technologies, so this is not a big deal in any case, but at least please lets try to get facts rights and not try to cast some kind of blame where there is none to cast. What is reasonable or not depends on the historical circumstances of development and deployment, and can be changed as needed, you can simply open an issue on the freeipa project and discuss there the pros and cons, if the current defaults are not ok for whatever reason, nobody will bite you. The reason why historically IPA *had to* allow to use a range below 65k is that we had compatibility requirements with older NFS and other Unix systems that could handle no more than 65535 ids (remember this project is now 17 years old and derive a lot from a project that is 30+ years old), and a systems of that era. > Let me emphasize again, right now, the UID range IPA takes possession > of collides on Fedora currently with: > > 1. classic UNIX users created via /etc/passwd adduser, >i.e. shadow-utils and stuff. As mentioned elsewhre, logind.defs >says this range goes to 60K, but IPA already starts before that. > 2. special Linux UIDs 65535, 65534 > 2. dynamic service users allocated via DynamicUser=1 in systemd unit >files > 3. systemd-homed users > > (and more...) Yeah this is simply misleading, FreeIPA *allows* an administrator to overlap those ranges for legacy compatibility reasons, but it has never been the default. Some of this is my fault. I responded earlier in the thread and cited (incorrectly) that the defaults covered a range from 10,000 - 2,010,000. My memory was faulty and I got the wrong offset for the low-end. Then I got sick yesterday and the conversation ran ahead without me being able to correct that misstatement. I can't seem to dig up the actual lower bound, but I think it's more like a range of 200,000 - 2,200,000 than my original statement. When we had our previous round of discussions with Lennart, I created a document that outlines FreeIPA identity mapping details. It is published at https://freeipa.readthedocs.io/en/latest/designs/id-mapping.html. Perhaps, it is still not enough to explain the field we are dealing with... > > > > Can you configure autologin for those uses cases (like kiosks or a home > > > > entertainment system) where that makes sense to do ? > > > > > > No you cannot, the security model relies on unlock keys to be provided > > > before the home directory is accessible. It's a strength of the model, > > > not a weakness, that user data is actually protected by the provided > > > user authentication credentials. > > > > So that is another use case that you need to know in advance before > > installation, how hard it is to "convert" the system if you made the > > incorrect choice? > > You can just copy out the files/chown them and add a classic UNIX user > record if you wish. Ok so this requires a highly skilled person, a regular person would have to create a new user from the UI (assuming it gives the option to specify what kind of home you get) and somehow copy data over from one account to the other, which is additional wo
Re: strawman proposal: homed directories for users
On Thu, Oct 10, 2024 at 5:23 PM Simo Sorce wrote: > > On Thu, 2024-10-10 at 17:29 +0200, Lennart Poettering wrote: > > On Mi, 09.10.24 11:12, Simo Sorce (s...@redhat.com) wrote: > > > > > > > > > This was again a reference to the fact that IPA folks aren't willing > > to restrict their allocations to some reasonable UID range, as > > mentoined elsewhere in this thread. > > > > Can you stop with this please? > This is absolutely not true is starting to become really annoying and > tiresome, let's please not do that. > > It has been explained to you by me (and in person years ago) and others > multiple times that FreeIPA has a fixed range it picks from, but to > allow *multiple* domains to interoperate it picks a subrange from that > big one fixed range, which is high up in the "millions* (I forget the > exact range but I think 1M-2M). > > As an example this is my personal domain user which I installed ages > ago and has this record: > > $ getent passwd simo > simo:*:164903:164903:Simo Sorce:/home/simo:/bin/bash > > As you can see there is no conflict with any reserved ID, please get > your facts straight. > > Now clearly older Unixes are dead, and NFS has finally come out of the > stone age and should be able to handle 32 bit ids everywhere, so there > is less need to allocate in a low range, but UIDs in long lived > organizations are really hard to change. At RH my Corporate uid is in > the low range for historical reasons (there have been at least two > migration through NIS and then LDAP servers and finally IPA since I > joined a couple of eons ago), and IPA serves it and it is fine. > > Just to be clear, IPA came out a more than a decade before systemd > started looking into any of this, and it was a more than decade after > Samba had already dealt with UID mapping in AD domains. > Ranges are always local and it is unlikely a system will need to use > two competing allocation technologies, so this is not a big deal in any > case, but at least please lets try to get facts rights and not try to > cast some kind of blame where there is none to cast. > > What is reasonable or not depends on the historical circumstances of > development and deployment, and can be changed as needed, you can > simply open an issue on the freeipa project and discuss there the pros > and cons, if the current defaults are not ok for whatever reason, > nobody will bite you. > > The reason why historically IPA *had to* allow to use a range below 65k > is that we had compatibility requirements with older NFS and other Unix > systems that could handle no more than 65535 ids (remember this project > is now 17 years old and derive a lot from a project that is 30+ years > old), and a systems of that era. > > > Let me emphasize again, right now, the UID range IPA takes possession > > of collides on Fedora currently with: > > > > 1. classic UNIX users created via /etc/passwd adduser, > >i.e. shadow-utils and stuff. As mentioned elsewhre, logind.defs > >says this range goes to 60K, but IPA already starts before that. > > 2. special Linux UIDs 65535, 65534 > > 2. dynamic service users allocated via DynamicUser=1 in systemd unit > >files > > 3. systemd-homed users > > > > (and more...) > > Yeah this is simply misleading, FreeIPA *allows* an administrator to > overlap those ranges for legacy compatibility reasons, but it has never > been the default. > Some of this is my fault. I responded earlier in the thread and cited (incorrectly) that the defaults covered a range from 10,000 - 2,010,000. My memory was faulty and I got the wrong offset for the low-end. Then I got sick yesterday and the conversation ran ahead without me being able to correct that misstatement. I can't seem to dig up the actual lower bound, but I think it's more like a range of 200,000 - 2,200,000 than my original statement. > > > > > Can you configure autologin for those uses cases (like kiosks or a > > > > > home > > > > > entertainment system) where that makes sense to do ? > > > > > > > > No you cannot, the security model relies on unlock keys to be provided > > > > before the home directory is accessible. It's a strength of the model, > > > > not a weakness, that user data is actually protected by the provided > > > > user authentication credentials. > > > > > > So that is another use case that you need to know in advance before > > > installation, how hard it is to "convert" the system if you made the > > > incorrect choice? > > > > You can just copy out the files/chown them and add a classic UNIX user > > record if you wish. > > Ok so this requires a highly skilled person, a regular person would > have to create a new user from the UI (assuming it gives the option to > specify what kind of home you get) and somehow copy data over from one > account to the other, which is additional work for mgmt tools. > > > > > As I understand the IPA/sssd model is a lot more traditional there, > > > > and does not consider the user's data as something to pr
Re: strawman proposal: homed directories for users
On Thu, 2024-10-10 at 17:29 +0200, Lennart Poettering wrote: > On Mi, 09.10.24 11:12, Simo Sorce (s...@redhat.com) wrote: > > > > > This was again a reference to the fact that IPA folks aren't willing > to restrict their allocations to some reasonable UID range, as > mentoined elsewhere in this thread. > Can you stop with this please? This is absolutely not true is starting to become really annoying and tiresome, let's please not do that. It has been explained to you by me (and in person years ago) and others multiple times that FreeIPA has a fixed range it picks from, but to allow *multiple* domains to interoperate it picks a subrange from that big one fixed range, which is high up in the "millions* (I forget the exact range but I think 1M-2M). As an example this is my personal domain user which I installed ages ago and has this record: $ getent passwd simo simo:*:164903:164903:Simo Sorce:/home/simo:/bin/bash As you can see there is no conflict with any reserved ID, please get your facts straight. Now clearly older Unixes are dead, and NFS has finally come out of the stone age and should be able to handle 32 bit ids everywhere, so there is less need to allocate in a low range, but UIDs in long lived organizations are really hard to change. At RH my Corporate uid is in the low range for historical reasons (there have been at least two migration through NIS and then LDAP servers and finally IPA since I joined a couple of eons ago), and IPA serves it and it is fine. Just to be clear, IPA came out a more than a decade before systemd started looking into any of this, and it was a more than decade after Samba had already dealt with UID mapping in AD domains. Ranges are always local and it is unlikely a system will need to use two competing allocation technologies, so this is not a big deal in any case, but at least please lets try to get facts rights and not try to cast some kind of blame where there is none to cast. What is reasonable or not depends on the historical circumstances of development and deployment, and can be changed as needed, you can simply open an issue on the freeipa project and discuss there the pros and cons, if the current defaults are not ok for whatever reason, nobody will bite you. The reason why historically IPA *had to* allow to use a range below 65k is that we had compatibility requirements with older NFS and other Unix systems that could handle no more than 65535 ids (remember this project is now 17 years old and derive a lot from a project that is 30+ years old), and a systems of that era. > Let me emphasize again, right now, the UID range IPA takes possession > of collides on Fedora currently with: > > 1. classic UNIX users created via /etc/passwd adduser, >i.e. shadow-utils and stuff. As mentioned elsewhre, logind.defs >says this range goes to 60K, but IPA already starts before that. > 2. special Linux UIDs 65535, 65534 > 2. dynamic service users allocated via DynamicUser=1 in systemd unit >files > 3. systemd-homed users > > (and more...) Yeah this is simply misleading, FreeIPA *allows* an administrator to overlap those ranges for legacy compatibility reasons, but it has never been the default. > > > > Can you configure autologin for those uses cases (like kiosks or a home > > > > entertainment system) where that makes sense to do ? > > > > > > No you cannot, the security model relies on unlock keys to be provided > > > before the home directory is accessible. It's a strength of the model, > > > not a weakness, that user data is actually protected by the provided > > > user authentication credentials. > > > > So that is another use case that you need to know in advance before > > installation, how hard it is to "convert" the system if you made the > > incorrect choice? > > You can just copy out the files/chown them and add a classic UNIX user > record if you wish. Ok so this requires a highly skilled person, a regular person would have to create a new user from the UI (assuming it gives the option to specify what kind of home you get) and somehow copy data over from one account to the other, which is additional work for mgmt tools. > > > As I understand the IPA/sssd model is a lot more traditional there, > > > and does not consider the user's data as something to protect? I'd > > > call that highly problematic, but I guess it's from a different time. > > > > It is not from a different time, it is from a different use case. > > In general you expect full disk encryption on corporate/centrally > > managed machines, not per-user encryption, unless you can escrow per- > > user encryption credentials, which I do not think systemd-homed is well > > positioned to do currently. > > I am pretty sure you want both, as mentioned: encryption of system > data to the TPM, and user data to a personal credential. For corporate machines FDE with a single escrow key is more cost effective so they prefer to do it that way, but I am agnostic here, each on
Re: strawman proposal: homed directories for users
On Mi, 09.10.24 20:17, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > Am 09.10.24 um 17:12 schrieb Simo Sorce: > > > Hence I am very curious where you think the security issues are? > > Sorry, I did not mean in any way to imply there are open security issue > > with systemd-homed, I meant only that we need to analyze the security > > assumptions in the context of making this a default and ensure we > > protect what we mean to protect, and address the risk profile we > > define. > > I want to add something here. FDE has two main purposes for mobile > devices (e.g. a Laptop): > > 1. prevent a thief of getting the data after the device is stolen > 2. prevent an attacker installing or exchanging installed software with > a version of their own (e.g. installing a keylogger) while the owner > isn't looking > > Number 1 is also taken care of by homed (if it does the encryption), if > you only have your data in your home directory (my father for example > does not, he has an extra disk with his most important data mounted to > ~/data, yes, mounted INTO his home directory). > > FDE alone obviously can't take care of number 2 alone, but needs at > least something like SecureBoot and a protected BIOS (or similar). But > if that's a given, it's pretty darn hard for attacker to do so (although > obviously not impossible, but I don't think there's a system where you > can say that). > With homed on the other hand, I don't think that would work. As far as I > understand it, things like SecureBoot only work up until including the > kernel, but not for e.g. the init system, or homed itself. So an > attacker could take the disk, mount it on one of his devices, exchange > some system software with their own version (after all, it's not checked > that this is an ok binary) and then put the disk back into the device. > > So, if you have a mobile device (like e.g. a Laptop), I don't think that > using JUST homed (even with SecureBoot) would be enough anyway. The model I am trying to push people towards is to guarantee OS integrity via Measured Boot, systemd brings a lot of infrastructure for that these days to provide TPM measurements, to manage TPM policies based on that, and to the hook up FDE to that. I think Secure Boot is much less interesting tech, since – at least in its incarnation for PCs – it is at best a very very wide allowlist of things, that because it is so unprecise is effectively just a denylist of known bad stuff, not more. A security policy linked to Measured Boot is a much fine grained approach, i.e. it can lock disk encryption to the OS vendor, the device vendor and its configuration. I wished Fedora would focus more on making Measured Boot by default a thing (other distros are working towards that, for example SUSE has been investing in that), but Fedora is not precisely leading in this effort right now. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Mi, 09.10.24 11:12, Simo Sorce (s...@redhat.com) wrote: > > I am pretty sure the security model is a lot cleaner than anything the > > sssd/IPA world would do, because we lock disk encryption to user > > provided credentials, FIDO2/PKCS#11 and such, and can suspend the home > > dir's encryption key on suspend. It should be a massive step up in > > security. > > You can lock a laptop disk via TPM and similar with clevis/tang as > well, w/o tying it to a single user, how you do it depends on what your > constraints are. I am pretty sure secure systems should lock down everything: the per-system stuff locked to a local TPM, and the per-user stuff locked to a password or FIDO2 token or so owned by the user. I'd suggest to avoid the tpm stuff in clevis/tang btw, the stuff systemd does natively is a ton more advanced, i.e. encrypts TPM communication on the bus, has a sane story around PCR updates and so on. > > No. systemd-homed user records are signed. User records not signed by > > a recognized key are not accepted. > > > > I am not sure if sssd/IPA stuff has something similar? is there any > > cryptographic integration protection part of its user database? > > SSSD/IPA only accept users from the domain they are bound to via the > keytab on the disk, all the data is authenticated that way, then stored > locally. The assumption is that the disk where the cache is stored is > encrypted of course. Right. homed's model is a lot stricter there, we generally require offline security, i.e. the user records themselves are protected cryptographically, we never rely on some storage hopefully being trusted. (in particular as FDE as typically deployed on linux doesn't even authenticate the data at all, strictly speaking, even though people assume it does) > > > Will it now allow this other user to access files and directories that > > > should be reserved to other users? > > > > No. At moment the binding of the home dir to the local host is > > established a free UID/GID is taken from a very specific range. This > > should make collisions unlikely. (though not impossible, because this > > system of course relies on everyone being equally careful before > > taking possession of a UID/GID, and as I understand the IPA world is > > systematically opposed to that, which is sad, but nothing I can > > change). > > I do not understand what you mean with this comment, in a domain all > UIDs are consistent, that said you can also do local assignment in > theory, it just is rarely a good idea (NFS doe snot support that, it is > the externalities of network protocols assuming consistent IDs that > force our hand in default configurations). This was again a reference to the fact that IPA folks aren't willing to restrict their allocations to some reasonable UID range, as mentoined elsewhere in this thread. Let me emphasize again, right now, the UID range IPA takes possession of collides on Fedora currently with: 1. classic UNIX users created via /etc/passwd adduser, i.e. shadow-utils and stuff. As mentioned elsewhre, logind.defs says this range goes to 60K, but IPA already starts before that. 2. special Linux UIDs 65535, 65534 2. dynamic service users allocated via DynamicUser=1 in systemd unit files 3. systemd-homed users (and more...) > > > Can you configure autologin for those uses cases (like kiosks or a home > > > entertainment system) where that makes sense to do ? > > > > No you cannot, the security model relies on unlock keys to be provided > > before the home directory is accessible. It's a strength of the model, > > not a weakness, that user data is actually protected by the provided > > user authentication credentials. > > So that is another use case that you need to know in advance before > installation, how hard it is to "convert" the system if you made the > incorrect choice? You can just copy out the files/chown them and add a classic UNIX user record if you wish. > > As I understand the IPA/sssd model is a lot more traditional there, > > and does not consider the user's data as something to protect? I'd > > call that highly problematic, but I guess it's from a different time. > > It is not from a different time, it is from a different use case. > In general you expect full disk encryption on corporate/centrally > managed machines, not per-user encryption, unless you can escrow per- > user encryption credentials, which I do not think systemd-homed is well > positioned to do currently. I am pretty sure you want both, as mentioned: encryption of system data to the TPM, and user data to a personal credential. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://
Re: strawman proposal: homed directories for users
On Wed, Oct 9, 2024 at 2:19 PM Kilian Hanich via devel < devel@lists.fedoraproject.org> wrote: > Am 09.10.24 um 17:12 schrieb Simo Sorce: > >> Hence I am very curious where you think the security issues are? > > Sorry, I did not mean in any way to imply there are open security issue > > with systemd-homed, I meant only that we need to analyze the security > > assumptions in the context of making this a default and ensure we > > protect what we mean to protect, and address the risk profile we > > define. > > I want to add something here. FDE has two main purposes for mobile > devices (e.g. a Laptop): > > 1. prevent a thief of getting the data after the device is stolen > 2. prevent an attacker installing or exchanging installed software with > a version of their own (e.g. installing a keylogger) while the owner > isn't looking > > Number 1 is also taken care of by homed (if it does the encryption), if > you only have your data in your home directory (my father for example > does not, he has an extra disk with his most important data mounted to > ~/data, yes, mounted INTO his home directory). > > FDE alone obviously can't take care of number 2 alone, but needs at > least something like SecureBoot and a protected BIOS (or similar). But > if that's a given, it's pretty darn hard for attacker to do so (although > obviously not impossible, but I don't think there's a system where you > can say that). > There's a caveat here - SecureBoot as currently implemented in Fedora does not give any protection against this type of attack, because the initrd - that prompts for your password - is not protected by SecureBoot. The rough plan that we came up a couple of years ago ( https://discussion.fedoraproject.org/t/future-of-encryption-in-fedora-desktop-variants/80397/19) was: - Encrypt everything but home directories using a TPM-sealed encryption key - and *no password* - Encrypt the home directories with user credentials (I wasn't sure at that point whether homed made sense, but there's been progress in GNOME integration, so it's more attractive these days) One of the things that has kept us from making progress here is that progress on Unified Kernel Images has been slow, and there's no firm plan about how to extend it to handle desktop/laptop installations. With homed on the other hand, I don't think that would work. As far as I > understand it, things like SecureBoot only work up until including the > kernel, but not for e.g. the init system, or homed itself. So an > attacker could take the disk, mount it on one of his devices, exchange > some system software with their own version (after all, it's not checked > that this is an ok binary) and then put the disk back into the device. Yes, but that's true of FDE as well, unless the initrd is protected by secure boot. (*) - Owen (*) Direct protection of the initrd would be refusing to run the initrd unless it was signed by an enrolled key. This is very hard to achieve - it requires the user to have a BIOS password, etc. This is why the plan was indirect protection - any initrd could run, but unless it was signed correctly, it would be unable to load the system partition encryption key from the TPM. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
Am 09.10.24 um 17:12 schrieb Simo Sorce: Hence I am very curious where you think the security issues are? Sorry, I did not mean in any way to imply there are open security issue with systemd-homed, I meant only that we need to analyze the security assumptions in the context of making this a default and ensure we protect what we mean to protect, and address the risk profile we define. I want to add something here. FDE has two main purposes for mobile devices (e.g. a Laptop): 1. prevent a thief of getting the data after the device is stolen 2. prevent an attacker installing or exchanging installed software with a version of their own (e.g. installing a keylogger) while the owner isn't looking Number 1 is also taken care of by homed (if it does the encryption), if you only have your data in your home directory (my father for example does not, he has an extra disk with his most important data mounted to ~/data, yes, mounted INTO his home directory). FDE alone obviously can't take care of number 2 alone, but needs at least something like SecureBoot and a protected BIOS (or similar). But if that's a given, it's pretty darn hard for attacker to do so (although obviously not impossible, but I don't think there's a system where you can say that). With homed on the other hand, I don't think that would work. As far as I understand it, things like SecureBoot only work up until including the kernel, but not for e.g. the init system, or homed itself. So an attacker could take the disk, mount it on one of his devices, exchange some system software with their own version (after all, it's not checked that this is an ok binary) and then put the disk back into the device. So, if you have a mobile device (like e.g. a Laptop), I don't think that using JUST homed (even with SecureBoot) would be enough anyway. Regards Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Tue, 2024-10-08 at 17:57 +0200, Lennart Poettering wrote: > On Mo, 07.10.24 12:59, Simo Sorce (s...@redhat.com) wrote: > > > > The homed approach would make other things possible too. For example, > > > sharing of /home in dual-boot scenarios. Right now a manual setup > > > needs to be done, and login details need to be propagated each time, > > > but with homed, dual-boot and reinstall are very similar scenarios, > > > so if we get one to work, we get the other one for free. > > > > > > Zbyszek > > > > The homed approach can work only in cases where you basically have only > > one user and all the OSs use the same approach. > > Hmm, what? No, homed works fine with multiple users. I have multiple > users right now on my local system. Here I was talking specifically about the case of a multi-boot system. In general it is not practical for large deployments to manually carry around all user data and allow mounting of the home on multiple systems. So it is by definition a "single user system", even though you can have multiple user drives, sorry for the confusion. > > > I see a few issues with security that needs to be addressed. > > Like what? Please be explicit, otherwise smells like FUD. Keep in mind my perspective is one of large deployments, not single system cared for by their own admin, so do not take my comment to the simple single-user case. > I am pretty sure the security model is a lot cleaner than anything the > sssd/IPA world would do, because we lock disk encryption to user > provided credentials, FIDO2/PKCS#11 and such, and can suspend the home > dir's encryption key on suspend. It should be a massive step up in > security. You can lock a laptop disk via TPM and similar with clevis/tang as well, w/o tying it to a single user, how you do it depends on what your constraints are. > Hence I am very curious where you think the security issues are? Sorry, I did not mean in any way to imply there are open security issue with systemd-homed, I meant only that we need to analyze the security assumptions in the context of making this a default and ensure we protect what we mean to protect, and address the risk profile we define. > > What happens if I plug a disk into a laptop that sports a "homed" > > directory, will the laptop suddenly allow a stranger to just login into > > the machine? > > No. systemd-homed user records are signed. User records not signed by > a recognized key are not accepted. > > I am not sure if sssd/IPA stuff has something similar? is there any > cryptographic integration protection part of its user database? SSSD/IPA only accept users from the domain they are bound to via the keytab on the disk, all the data is authenticated that way, then stored locally. The assumption is that the disk where the cache is stored is encrypted of course. > > What happens if there are conflicts of uid or gid ? > > In the systemd-homed world uid/gid are assigned when the home dir is > first activated on a host. A free UID/GID is allocated then, and > idmapping is used to ensure that the home dir appears owned by the > right user (or in other words: on disk all files are owned by > user/group "nobody", only the idmapping makes them appear owned by the > user locally). This UID/GID binding is persisted on the local system, > but can differ between systems. > > > Will it now allow this other user to access files and directories that > > should be reserved to other users? > > No. At moment the binding of the home dir to the local host is > established a free UID/GID is taken from a very specific range. This > should make collisions unlikely. (though not impossible, because this > system of course relies on everyone being equally careful before > taking possession of a UID/GID, and as I understand the IPA world is > systematically opposed to that, which is sad, but nothing I can > change). I do not understand what you mean with this comment, in a domain all UIDs are consistent, that said you can also do local assignment in theory, it just is rarely a good idea (NFS doe snot support that, it is the externalities of network protocols assuming consistent IDs that force our hand in default configurations). > > > What happen if you want to change the user to be a corporate directory > > provided one? > > Enterprisey IPA/SSSD/AD/LDAP style stuff really is not in focus for > systemd-homed, as mentioned many times. Ok, so this already means that Fedora would need 2 different behaviors in the single user vs laptop in a domain configuration. That is an important thing to point out. > > Can you configure autologin for those uses cases (like kiosks or a home > > entertainment system) where that makes sense to do ? > > No you cannot, the security model relies on unlock keys to be provided > before the home directory is accessible. It's a strength of the model, > not a weakness, that user data is actually protected by the provided > user authentication credentials. So that is another us
Re: strawman proposal: homed directories for users
> On 9 Oct 2024, at 10:04, Zbigniew Jędrzejewski-Szmek > wrote: > > On Tue, Oct 08, 2024 at 06:14:29PM +0100, Barry Scott wrote: >>> On 4 Oct 2024, at 16:05, Zbigniew Jędrzejewski-Szmek >>> wrote: >>> >>> Hi folks, >>> >>> I was recently doing a bunch of test reinstalls of Fedora [1], >>> looking to see if it's complicated to retain the user directories >>> during a reinstall. The answer is, sadly, that it's possible only with >>> some manual tinkering. This is a known problem [2]. >>> >>> With a little bit of trickery, Anaconda will let the "home" subvolume >>> be and install the system to a new "root" subvolume, so user data is >>> preserved. But then after a reboot a new user will be created, because >>> the old user is not hooked up into /etc/passwd. >>> >>> We actually have a partial solution for this: systemd-homed. >>> With systemd-homed the information about the user is maintained in the >>> user directory/subvolume/partition, e.g. /home/username.homedir. >>> After a reinstall, ideally nothing needs to be done and the user >>> account is ready to be used. >> >> I like the idea of being able to reinstall and keep the /home. >> But I'd rather not use systemd-homed to get the feature. >> I already have full-disk-encryption for security. >> >> What about having the necessary meta data in a per user file in /home >> and read that when doing the reinstall? >> >> I would have /home/barry and /home/barry.metadata for example. > > What you describe is pretty much the proposal you were replying to, > just with different paths. You'd have (unencrypted) > /home/barry.homedir/ and /home/barry.homedir/.identity and > systemd-homed would create /home/barry/ with a bind mount. > You mention FDE, but the proposal was explicitly about homed homes > without encryption at the homed level. This kind of setup is often > used with FDE. I'll search for the docs on this style of use. Thanks for the heads up. Barry > > Zbyszek > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Tue, Oct 08, 2024 at 06:14:29PM +0100, Barry Scott wrote: > > On 4 Oct 2024, at 16:05, Zbigniew Jędrzejewski-Szmek > > wrote: > > > > Hi folks, > > > > I was recently doing a bunch of test reinstalls of Fedora [1], > > looking to see if it's complicated to retain the user directories > > during a reinstall. The answer is, sadly, that it's possible only with > > some manual tinkering. This is a known problem [2]. > > > > With a little bit of trickery, Anaconda will let the "home" subvolume > > be and install the system to a new "root" subvolume, so user data is > > preserved. But then after a reboot a new user will be created, because > > the old user is not hooked up into /etc/passwd. > > > > We actually have a partial solution for this: systemd-homed. > > With systemd-homed the information about the user is maintained in the > > user directory/subvolume/partition, e.g. /home/username.homedir. > > After a reinstall, ideally nothing needs to be done and the user > > account is ready to be used. > > I like the idea of being able to reinstall and keep the /home. > But I'd rather not use systemd-homed to get the feature. > I already have full-disk-encryption for security. > > What about having the necessary meta data in a per user file in /home > and read that when doing the reinstall? > > I would have /home/barry and /home/barry.metadata for example. What you describe is pretty much the proposal you were replying to, just with different paths. You'd have (unencrypted) /home/barry.homedir/ and /home/barry.homedir/.identity and systemd-homed would create /home/barry/ with a bind mount. You mention FDE, but the proposal was explicitly about homed homes without encryption at the homed level. This kind of setup is often used with FDE. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Di, 08.10.24 22:21, Chris Murphy (li...@colorremedies.com) wrote: > >> And at least on my setup with many read-only snapshots in > >> ~/, permissions changes wouldn't be permitted, even by the root > >> user. > > > > Not sure I grok what you are trying to say here? > > Read-only snapshot contents are immutable, even by the root user. Sure, but that's fine in an idmapped world. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Mi, 09.10.24 09:59, Lennart Poettering (mzerq...@0pointer.de) wrote: > That said, for compat with traditional subuid/subgid as per the table > on https://systemd.io/UIDS-GIDS the UID/GID range 524288…1879048191 is > mapped 1:1 on homed homes, thus if you use those things work as > before. Just to add that this, on Fedora, as per login.defs: SUB_UID_MIN524288 SUB_UID_MAX 60010 Thus, you should all be set, by default, if you want to use subuid/subgid. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Di, 08.10.24 11:42, Chris Adams (li...@cmadams.net) wrote: > Once upon a time, Lennart Poettering said: > > Oh, that hasn't been the case for a long time anymore. Nowadays files > > on disk are owned by the "nobody" user always, and idmapped mounts are > > used to map them transiently to the UID/GID assigned to the user on > > the local machine. > > How do rootless containers work (with subuid/subgid) in that setup? I think subuid/subgid is highly problematic and should go away. We have better mechanisms these days, via idmapping (i.e. container files on disk should never be owned by the uid/gid ranges they are actually run in, but those should be dynamically allocated and mapped dynamically via idmapping to the physical UID/GID range on disk) That said, for compat with traditional subuid/subgid as per the table on https://systemd.io/UIDS-GIDS the UID/GID range 524288…1879048191 is mapped 1:1 on homed homes, thus if you use those things work as before. But again, just don't, subuid/subgid is a mistake if you ask me. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Di, 08.10.24 12:46, Stephen Gallagher (sgall...@redhat.com) wrote: > I suspect you're talking past one another here; in practice, IPA has a > random set of ID ranges that (IIRC) essentially owns the ID space of > 10,000 - 2,010,000. (It's possible for the installer to set an > arbitrary range outside that, but it's a custom choice). So you could > probably reserve the IDs above 20,010,000 for homed in that situation. Uh, that seems like a problematic choice for IPA. First of all within that range is the UID 65534, i.e. the linux nobody/overflow/unmapped UID. You should not delegate this UID for any users. Moreover, 65535 (the -1 value in 16bit) is special, as it indicates "don't change" in various legacy APIs, old file systems and so on. Newer apis generally use 4294967295 for that (i.e. -1 in 32bit), but for compat 65535 should be avoided to. If you so will, the uids 0, 65534, 65535, 4294967295 all have some special meaning to Linux, and should not be used for regular users. Hence it's highly problematic if IPA just delegates 65534 or 65535 to its regular users, as you appear to suggest. But there's more: container managers typically do not delegate more than 64K UIDs to containers (that's what nspawn does, and as I understand, other container managers map even less space by default). Yes, you can delegate more if you do extra work, but it's not what happens by default. This means, UIDs < 2^16 are more "valuable" than those >= 2^16. In particular for stuff that shall "just work" inside of containers it's kinda relevant to stick to ranges < 2^16. (systemd-homed's local UID allocations qualify as that) With your definitions above you basically take most of that range for IPA as private property, and I think that's just not OK, it's leaves no space for anyone else in the 16bit range really (under the assumption that 1000…6 are for classic /etc/passwd users, which is what Fedora's login.defs dictates). (BTW: talking about login.defs: if IPA wants to take possession from UID range 1 on, you are conflicting with Fedora's login.defs definition which assigns the range 1000…6 to regular users, i.e. /etc/passwd) Hence, what I'd like to ask IPA to do do is first of all stay away from the 65534 + 65535 UIDs, that's just a major bug if you ask me. I'd then like IPA to say away from the regular user range declared in login.defs, i.e. UIDs < 60K. But also: leave some room in the 16bit range, outside of the regular user range for other users. My suggestion: change IPA to allocate from the range 65536…524287 range or so. Or alternatively from 1879048192…2147483647, which would mean it wouldn't conflict with anything else anymore. I understand that existing IPA deployments ignore all this, and that's bad but hard to change. But at the very least, maybe for future installations suggest better ranges. We documented all our UID assignments and their reasons here: https://systemd.io/UIDS-GIDS/ It would be very wise if IPA maintained a similar document with its assignments, and similar considerations regarding the special UID ranges and everything. Double assignments like the login.defs or overflow UID stuff really should be avoided, and good documentation helps for that. I'd also be happy to update the UID/GID table on aforementioned systemd documentation and delegate some range explicitly to IPA (or IPA-like usecases) there, but for that I'd need some committment that at least future IPA installations would honour it. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Tue, Oct 8, 2024, at 1:14 PM, Barry Scott wrote: > I like the idea of being able to reinstall and keep the /home. > But I'd rather not use systemd-homed to get the feature. It's an explicit feature request for the new installer's "Guided" partitioning path. The current UI (also for Fedora 41) requires the use of the Custom/Manual partitioning path, and for the user to know there's a several tricks. [1] It would be nice to have a spec on how to do this without user intervention, and have the installer and homed use it. [1] One is a little obvious, you need to locate and click on the existing home subvolume and assign it to the `/home` mount point. But the second trick is not at all obvious. You need to click on + to add a new mount point, specify `/` as the mounpoint, and leave the capacity field blank. Do this and the installer creates a new subvolume on the existing Btrfs for the use of `/` with your existing (populated) `/home` subvolume. Still another is UID matching, since the new /etc/passwd doesn't have your user added yet - at least with Workstation edition, the new user is created by GNOME Initial Setup. If it's a single user setup, the UID for the first user created is 1000, and so if you just go through that part of GNOME Initial Setup again, it will create the entry in /etc/passwd, but will not touch the existing directory in `/home` for UID 1000, but if something is off - well I haven't tested that. So there could be some fragility here. > I already have full-disk-encryption for security. > > What about having the necessary meta data in a per user file in /home > and read that when doing the reinstall? Perhaps set an XATTR on such a subvolume, so that only subvolumes with the XATTR are searched for this metadata? Btrfs supports 2^64 subvolumes. A casual user could easily have hundreds. -- Chris Murphy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Tue, Oct 8, 2024, at 11:59 AM, Lennart Poettering wrote: > On Mo, 07.10.24 20:55, Chris Murphy (li...@colorremedies.com) wrote: > >> And at least on my setup with many read-only snapshots in >> ~/, permissions changes wouldn't be permitted, even by the root >> user. > > Not sure I grok what you are trying to say here? Read-only snapshot contents are immutable, even by the root user. -- Chris Murphy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
> On 4 Oct 2024, at 16:05, Zbigniew Jędrzejewski-Szmek > wrote: > > Hi folks, > > I was recently doing a bunch of test reinstalls of Fedora [1], > looking to see if it's complicated to retain the user directories > during a reinstall. The answer is, sadly, that it's possible only with > some manual tinkering. This is a known problem [2]. > > With a little bit of trickery, Anaconda will let the "home" subvolume > be and install the system to a new "root" subvolume, so user data is > preserved. But then after a reboot a new user will be created, because > the old user is not hooked up into /etc/passwd. > > We actually have a partial solution for this: systemd-homed. > With systemd-homed the information about the user is maintained in the > user directory/subvolume/partition, e.g. /home/username.homedir. > After a reinstall, ideally nothing needs to be done and the user > account is ready to be used. I like the idea of being able to reinstall and keep the /home. But I'd rather not use systemd-homed to get the feature. I already have full-disk-encryption for security. What about having the necessary meta data in a per user file in /home and read that when doing the reinstall? I would have /home/barry and /home/barry.metadata for example. Barry > > The primary purpose of systemd-homed is to use per-user encryption > using loopback devices. This still has various problem related to > resizing and suspend. Work is being done [see 3,4 for recent developments], > but it's not at a point where we can recommend it. > But systemd-homed has a mode where the user "home" is just a normal > directory or btrfs subvolume with some metadata stored in files [5]. > Some work would be needed [6] to make this work smoothly, but it > doesn't seem like too much. (Mostly filing down some rough edges > in systemd-homed and adding pam_home_systemd and nss_systemd > in various authselect profiles.) > > Thus the question: would this be something worth looking into? > > [1] > https://discussion.fedoraproject.org/t/feedback-anaconda-web-ui-partitioning/108995/65 > [2] > https://discussion.fedoraproject.org/t/its-difficult-to-reformat-a-btrfs-partition-subvolume-in-the-installer/89052 > [3] https://cfp.all-systems-go.io/all-systems-go-2024/talk/FFY3BB/ > [4] https://www.youtube.com/watch?v=3e3IhBBU0JY > [5] https://systemd.io/HOME_DIRECTORY/ > [6] When I tested this today, this actually doesn't work. >systemd-homed does a misguided check that break reinstalls. >We'd need to figure out some solution here. Most likely just >conditionalize that part of the code. > > Zbyszek > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Tue, Oct 8, 2024 at 12:35 PM Lennart Poettering wrote: > > On Di, 08.10.24 12:23, Stephen Gallagher (sgall...@redhat.com) wrote: > > > On Tue, Oct 8, 2024 at 12:19 PM Lennart Poettering > > wrote: > > > > > > On Di, 08.10.24 18:07, Fedora Development ML > > > (devel@lists.fedoraproject.org) wrote: > > > > > > > Am 08.10.24 um 17:32 schrieb Lennart Poettering: > > > > > For example, I am fundamentally opposed to the model > > > > > these systems generally pursue of turning UID numbers into centrally, > > > > > organization-wide managed concepts. > > > > Wait a second, some organization have more than 70k people (and in this > > > > day and age, they all require their own accounts) and UIDs are (on > > > > Linux) 16bit numbers (which means a max of 65536 possible values). > > > > > > uid_t is 32bit. > > > > > > See https://systemd.io/UIDS-GIDS for our (i.e. systemd's) take on UID > > > ranges and how much is actually available from the 32bit for what. > > > > > > (Note that this document does not take IPA world into account, which > > > doesn't really subscribe to the idea that projects should allocate > > > from specific UID subranges only, and wants to own the whole range > > > instead. Sad.) > > > > I'm not sure where you got that from... > > > > "By default, an IdM ID range is automatically assigned during the IdM > > server installation. The ipa-server-install command randomly selects > > and assigns a range of 200,000 IDs from a total of 10,000 possible > > ranges. Selecting a random range in this way significantly reduces the > > probability of conflicting IDs in case you decide to merge two > > separate IdM domains in the future." > > > > You can select this range explicitly when setting up the domain and > > you can add more 200k ranges later (though the first one you create is > > immutable). > > > > [1] > > https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/adjusting-id-ranges-manually_configuring-and-managing-idm#automatic-id-ranges-assignment_adjusting-id-ranges-manually > > Comments like this from @abbra: > > https://github.com/systemd/systemd/pull/30846#issuecomment-1884526052 > > Apparently the ranges are always configurable in IPA, and which ranges > are used is stored in LDAP. This makes the logic systematically > incompatible with various low-level uses where we need to classify > UIDs in a very basic way, but cannot possibly consult any external > database, IPC, or even network stuff. > > It would all be very easy if IPA would just stick to one range of > UIDs, and allocate from that, but apparently IPA really wants this to > be entirely configurable as I understand. > I suspect you're talking past one another here; in practice, IPA has a random set of ID ranges that (IIRC) essentially owns the ID space of 10,000 - 2,010,000. (It's possible for the installer to set an arbitrary range outside that, but it's a custom choice). So you could probably reserve the IDs above 20,010,000 for homed in that situation. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
Once upon a time, Lennart Poettering said: > I am pretty sure all files inside of a home dir should carry the same > selinux label, identifying it as a user's file. That's incorrect, as there are a variety of restricted things, starting as basic as SSH keys and authorized hosts. -- Chris Adams -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Tuesday 8 October 2024 17:07:53 BST Kilian Hanich via devel wrote: > Am 08.10.24 um 17:32 schrieb Lennart Poettering: > > > For example, I am fundamentally opposed to the model > > these systems generally pursue of turning UID numbers into centrally, > > organization-wide managed concepts. > > Wait a second, some organization have more than 70k people (and in this > day and age, they all require their own accounts) and UIDs are (on > Linux) 16bit numbers (which means a max of 65536 possible values). > > Does somebody know or have an idea of how they make that work? > I worked at a place with more than 70k user accounts; we used 32 bit UIDs on Linux for this purpose. Linux UIDs are 32 bit since 2.4 days, not 16 bit. -- Simon Farnsworth -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
Once upon a time, Lennart Poettering said: > Oh, that hasn't been the case for a long time anymore. Nowadays files > on disk are owned by the "nobody" user always, and idmapped mounts are > used to map them transiently to the UID/GID assigned to the user on > the local machine. How do rootless containers work (with subuid/subgid) in that setup? -- Chris Adams -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Di, 08.10.24 12:23, Stephen Gallagher (sgall...@redhat.com) wrote: > On Tue, Oct 8, 2024 at 12:19 PM Lennart Poettering > wrote: > > > > On Di, 08.10.24 18:07, Fedora Development ML > > (devel@lists.fedoraproject.org) wrote: > > > > > Am 08.10.24 um 17:32 schrieb Lennart Poettering: > > > > For example, I am fundamentally opposed to the model > > > > these systems generally pursue of turning UID numbers into centrally, > > > > organization-wide managed concepts. > > > Wait a second, some organization have more than 70k people (and in this > > > day and age, they all require their own accounts) and UIDs are (on > > > Linux) 16bit numbers (which means a max of 65536 possible values). > > > > uid_t is 32bit. > > > > See https://systemd.io/UIDS-GIDS for our (i.e. systemd's) take on UID > > ranges and how much is actually available from the 32bit for what. > > > > (Note that this document does not take IPA world into account, which > > doesn't really subscribe to the idea that projects should allocate > > from specific UID subranges only, and wants to own the whole range > > instead. Sad.) > > I'm not sure where you got that from... > > "By default, an IdM ID range is automatically assigned during the IdM > server installation. The ipa-server-install command randomly selects > and assigns a range of 200,000 IDs from a total of 10,000 possible > ranges. Selecting a random range in this way significantly reduces the > probability of conflicting IDs in case you decide to merge two > separate IdM domains in the future." > > You can select this range explicitly when setting up the domain and > you can add more 200k ranges later (though the first one you create is > immutable). > > [1] > https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/adjusting-id-ranges-manually_configuring-and-managing-idm#automatic-id-ranges-assignment_adjusting-id-ranges-manually Comments like this from @abbra: https://github.com/systemd/systemd/pull/30846#issuecomment-1884526052 Apparently the ranges are always configurable in IPA, and which ranges are used is stored in LDAP. This makes the logic systematically incompatible with various low-level uses where we need to classify UIDs in a very basic way, but cannot possibly consult any external database, IPC, or even network stuff. It would all be very easy if IPA would just stick to one range of UIDs, and allocate from that, but apparently IPA really wants this to be entirely configurable as I understand. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Di, 08.10.24 09:24, Neal Gompa (ngomp...@gmail.com) wrote: > On Tue, Oct 8, 2024 at 9:22 AM Michael Catanzaro > wrote: > > > > On Mon, Oct 7 2024 at 12:59:46 PM -04:00:00, Simo Sorce > > wrote: > > > Changing a default like this is not something to do lightly IMHO. > > > > I'm interested in systemd-homed because we currently have no other > > plausible path towards encryption of user data by default [1] (since > > use of LUKS full-disk encryption has been rejected). > > > > [1] https://pagure.io/fedora-workstation/issue/82 > > And that's the context in which we wanted homed working with > centralized logins. It continues to confuse me that people conflate > "centralized login provider" with "remote users", which are not the > same thing at all. Local users that have primary > authentication/authorization externally managed has been a pattern for > quite a long time on other platforms. So one thing I am kinda interested in is adding support for synthesizing local homed users from oidc/oauth2 accounts, in the long run, to get something like a Chromebook-like behaviour, that you can basically say "allow logins from any @google.com" account or similar, and we'd generate a home dir from that automatically, as you log in. But quite frankly, we have more pressing issues in systemd-homed land right now. It's a bigger project, would require support in various layers, i.e. gdm would probably need to support some form of web browser and so on. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Tue, Oct 8, 2024 at 12:19 PM Lennart Poettering wrote: > > On Di, 08.10.24 18:07, Fedora Development ML (devel@lists.fedoraproject.org) > wrote: > > > Am 08.10.24 um 17:32 schrieb Lennart Poettering: > > > For example, I am fundamentally opposed to the model > > > these systems generally pursue of turning UID numbers into centrally, > > > organization-wide managed concepts. > > Wait a second, some organization have more than 70k people (and in this > > day and age, they all require their own accounts) and UIDs are (on > > Linux) 16bit numbers (which means a max of 65536 possible values). > > uid_t is 32bit. > > See https://systemd.io/UIDS-GIDS for our (i.e. systemd's) take on UID > ranges and how much is actually available from the 32bit for what. > > (Note that this document does not take IPA world into account, which > doesn't really subscribe to the idea that projects should allocate > from specific UID subranges only, and wants to own the whole range > instead. Sad.) I'm not sure where you got that from... "By default, an IdM ID range is automatically assigned during the IdM server installation. The ipa-server-install command randomly selects and assigns a range of 200,000 IDs from a total of 10,000 possible ranges. Selecting a random range in this way significantly reduces the probability of conflicting IDs in case you decide to merge two separate IdM domains in the future." You can select this range explicitly when setting up the domain and you can add more 200k ranges later (though the first one you create is immutable). [1] https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/adjusting-id-ranges-manually_configuring-and-managing-idm#automatic-id-ranges-assignment_adjusting-id-ranges-manually -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Di, 08.10.24 18:07, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > Am 08.10.24 um 17:32 schrieb Lennart Poettering: > > For example, I am fundamentally opposed to the model > > these systems generally pursue of turning UID numbers into centrally, > > organization-wide managed concepts. > Wait a second, some organization have more than 70k people (and in this > day and age, they all require their own accounts) and UIDs are (on > Linux) 16bit numbers (which means a max of 65536 possible values). uid_t is 32bit. See https://systemd.io/UIDS-GIDS for our (i.e. systemd's) take on UID ranges and how much is actually available from the 32bit for what. (Note that this document does not take IPA world into account, which doesn't really subscribe to the idea that projects should allocate from specific UID subranges only, and wants to own the whole range instead. Sad.) Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Mo, 07.10.24 14:15, Alexander Bokovoy (aboko...@redhat.com) wrote: > > > https://github.com/fedora-selinux/selinux-policy/pull/939#issuecomment-1409217811 > > > No follow up happened on that, sadly. > > > > > > I do not see any work done on that yet. Without having SELinux support > > > properly integrated, I think enabling systemd-homed by default is > > > premature. > > > > > Actually selinux-policy has support for systemd-homed in F41 and F42 since > > Sep 24th. > > Thanks, though this is about the first part (selinux-policy allowing > systemd-homed to access its own default home directory), while the > github comment talks about drives that systemd-homed creates for user > homes. That part needs to be addressed in systemd-homed, if I understand > correctly, pretty much like we address labeling of auto-created home > directories in oddjob. I am pretty sure all files inside of a home dir should carry the same selinux label, identifying it as a user's file. Because everything else makes home directories unportable, because local system policy will leak into the homedirs. Moreover SELinux policy even if it wanted couldn#t really express fine-grained app policy, since it's a centralized thing, and we live in a world where apps are built and distributed outside fedora, with flatpak and stuff. The assumption that every app comes via fedora, and hence can come with selinux database/policy also shipped by fedora to match it is just unrealistic in today's world. There's an upstream issue about all this: https://github.com/systemd/systemd/issues/30580 It's kinda stuck, because the overlap of folks deeply interested in homed and deeply interested in selinux is kinda small to non-existing. Anyway, if all people want is to stick another "relabel" this call after we create a new homedir, i am fine with that, but this would be not be a full fix in my eyes. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
Am 08.10.24 um 17:32 schrieb Lennart Poettering: For example, I am fundamentally opposed to the model these systems generally pursue of turning UID numbers into centrally, organization-wide managed concepts. Wait a second, some organization have more than 70k people (and in this day and age, they all require their own accounts) and UIDs are (on Linux) 16bit numbers (which means a max of 65536 possible values). Does somebody know or have an idea of how they make that work? Regards Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Mo, 07.10.24 20:55, Chris Murphy (li...@colorremedies.com) wrote: > > What happens if there are conflicts of uid or gid ? > > uid/gid are recursively changed at mount time to avoid > conflicts. For large homes, this could result in a lot of metadata > writes. Oh, that hasn't been the case for a long time anymore. Nowadays files on disk are owned by the "nobody" user always, and idmapped mounts are used to map them transiently to the UID/GID assigned to the user on the local machine. Or in other words, it's basically free, now. > And at least on my setup with many read-only snapshots in > ~/, permissions changes wouldn't be permitted, even by the root > user. Not sure I grok what you are trying to say here? Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Mo, 07.10.24 12:59, Simo Sorce (s...@redhat.com) wrote: > > The homed approach would make other things possible too. For example, > > sharing of /home in dual-boot scenarios. Right now a manual setup > > needs to be done, and login details need to be propagated each time, > > but with homed, dual-boot and reinstall are very similar scenarios, > > so if we get one to work, we get the other one for free. > > > > Zbyszek > > The homed approach can work only in cases where you basically have only > one user and all the OSs use the same approach. Hmm, what? No, homed works fine with multiple users. I have multiple users right now on my local system. > I see a few issues with security that needs to be addressed. Like what? Please be explicit, otherwise smells like FUD. I am pretty sure the security model is a lot cleaner than anything the sssd/IPA world would do, because we lock disk encryption to user provided credentials, FIDO2/PKCS#11 and such, and can suspend the home dir's encryption key on suspend. It should be a massive step up in security. Hence I am very curious where you think the security issues are? > What happens if I plug a disk into a laptop that sports a "homed" > directory, will the laptop suddenly allow a stranger to just login into > the machine? No. systemd-homed user records are signed. User records not signed by a recognized key are not accepted. I am not sure if sssd/IPA stuff has something similar? is there any cryptographic integration protection part of its user database? > What happens if there are conflicts of uid or gid ? In the systemd-homed world uid/gid are assigned when the home dir is first activated on a host. A free UID/GID is allocated then, and idmapping is used to ensure that the home dir appears owned by the right user (or in other words: on disk all files are owned by user/group "nobody", only the idmapping makes them appear owned by the user locally). This UID/GID binding is persisted on the local system, but can differ between systems. > Will it now allow this other user to access files and directories that > should be reserved to other users? No. At moment the binding of the home dir to the local host is established a free UID/GID is taken from a very specific range. This should make collisions unlikely. (though not impossible, because this system of course relies on everyone being equally careful before taking possession of a UID/GID, and as I understand the IPA world is systematically opposed to that, which is sad, but nothing I can change). > What happen if you want to change the user to be a corporate directory > provided one? Enterprisey IPA/SSSD/AD/LDAP style stuff really is not in focus for systemd-homed, as mentioned many times. > Can you configure autologin for those uses cases (like kiosks or a home > entertainment system) where that makes sense to do ? No you cannot, the security model relies on unlock keys to be provided before the home directory is accessible. It's a strength of the model, not a weakness, that user data is actually protected by the provided user authentication credentials. As I understand the IPA/sssd model is a lot more traditional there, and does not consider the user's data as something to protect? I'd call that highly problematic, but I guess it's from a different time. Note that systemd-homed is *one* provider of user accounts, but it's not to be the only one. The way I see it there are always multiple in play: 1. static system users configured via /etc/passwd, /etc/shadow & co. 2. dynamic system users allocated via systemd's DynamicUser=1 3. systemd-homed ones for high-security, local users 4. traditional unix users configured via /etc/passwd, /etc/shadow & co. 5. sssd provided ones for networked enterprise accounts Of course, item 1 and 4 are the same pretty much, just differ in UID range. In your kiosk usecase always opt for option 4 I think. > Is this tied to a specific file system type? homed has various backends. If you use the LUKS backend you really want to use btrfs, because it allows both online grow & shrink. Other file systems are a lot more limited, but also supported for the LUKS backend. But there's also a plain directory backend where we make almost any restrictions (at weaker security of course). And there's an fscrypt backend (which only requires an fs that supports fscrypt), at mid-level security (because fscrypt protectes file contents, not metadata, unlike the LUKS/dm-crypt backend which protects everything.) Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, re
Re: strawman proposal: homed directories for users
On Sa, 05.10.24 10:53, Alexander Bokovoy (aboko...@redhat.com) wrote: > > The homed approach would make other things possible too. For example, > > sharing of /home in dual-boot scenarios. Right now a manual setup > > needs to be done, and login details need to be propagated each time, > > but with homed, dual-boot and reinstall are very similar scenarios, > > so if we get one to work, we get the other one for free. > > Can we move systemd-homed configuration and activation into something > that could be explicitly enabled by the administrators? Whether this is > done during installation or post, it still would need to be a concious > step made by admins. It's activated on-demand only. It should not take much resources hence. > Right now systemd-homed is activated on each system without ask for it, > even on systems that do not benefit from its use (see parallel > discussion by Neal). I also see it as a sole contributor to SELinux AVCs > in OpenQA tests we run for FreeIPA use cases. That seems like a bug in the SELinux policy really. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Mo, 07.10.24 20:42, Chris Murphy (li...@colorremedies.com) wrote: > > You should be able to combine the three sources of users freely > > without problems – if you like. But these three sources of user > > definitions should be on similar footing, and not try to abstract each > > other. > > > > Hence: if you have some user in ldap/ipa, and another in homed, that's > > entirely fine, they should not affect each other. > > Supporting local encrypted user data with centralized authentication > methods is desired. Why implement this outside of systemd-homed > rather than within it? The former seems like a duplicated effort. Well, for starters, there's quite a philosophical gap between how I personally (and homed being my design, this kinda is built into the thing) think home dirs should be managed, and how the IPA/AD/SSSD worlds do it. For example, I am fundamentally opposed to the model these systems generally pursue of turning UID numbers into centrally, organization-wide managed concepts. I am pretty sure they should remain locally managed artifacts of a binding of a user record to the local system. One of the reason homed exists is to break with the concept of trying to manage UIDs organization-wise. And there's a lot more, for example it's fundamental to homed that access to home dirs is unavailable unless the user is logged in, and authentication keys for the data itself are provided. That breaks with fundamental assumptions baked into much UNIX software, which however is stuff the classic centralized enterprise world really cares about. So yes, from a distanced view you might think: both ipa and homed manage home dirs, so why not make that one. But conceptually, philosophically the two things are *so* different I really don't think one should attempt to make them one thing. Note that in systemd's infrastructure we have three components for managing users/sessions: 1. systemd-logind → manages logged in user sessions and related stuff 2. systemd-userdbd → manages JSON users/group records, going far beyond "struct passwd" and friends 3. systemd-homed → manages encrypted local home dirs These three things are separate on purpose. They integrate closely if used together, i.e. systemd-homed provides user records to systemd-userdbd, and systemd-logind reads them from systemd-userdbd, so that homed can set various things such as security and resource control settings that logind then enforces. But the interfaces between the three are open and documented, hence if sssd wants it can very well plug into systemd-userdbd the same way as systemd-homed does, and then take benefit of systemd-logind resource logic too. So far there's was literal interest in that though. But yeah, would be great if sssd/ipa world would integrate with systemd-logind/systemd-userdbd and all that stuff more tightly, but that should be on equal footing with systemd-homed, and not inside of systemd-homed or so. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Tue, 2024-10-08 at 08:22 -0500, Michael Catanzaro wrote: > On Mon, Oct 7 2024 at 12:59:46 PM -04:00:00, Simo Sorce > wrote: > > Changing a default like this is not something to do lightly IMHO. > > I'm interested in systemd-homed because we currently have no other > plausible path towards encryption of user data by default [1] (since > use of LUKS full-disk encryption has been rejected). > > [1] https://pagure.io/fedora-workstation/issue/82 It is a too long issue to understand all the details, but honestly for a laptop it seem misguided to me not to use LUKS if you care about protecting the whole data and do not fully understand what is the problem of using it, then again I do not use btrfs and always set up LUKS on my own by customizing installation, and as long as these changes do not break customization I guess experimentation is reasonable. Simo. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Tue, Oct 8, 2024 at 9:22 AM Michael Catanzaro wrote: > > On Mon, Oct 7 2024 at 12:59:46 PM -04:00:00, Simo Sorce > wrote: > > Changing a default like this is not something to do lightly IMHO. > > I'm interested in systemd-homed because we currently have no other > plausible path towards encryption of user data by default [1] (since > use of LUKS full-disk encryption has been rejected). > > [1] https://pagure.io/fedora-workstation/issue/82 > And that's the context in which we wanted homed working with centralized logins. It continues to confuse me that people conflate "centralized login provider" with "remote users", which are not the same thing at all. Local users that have primary authentication/authorization externally managed has been a pattern for quite a long time on other platforms. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Mon, Oct 7 2024 at 12:59:46 PM -04:00:00, Simo Sorce wrote: Changing a default like this is not something to do lightly IMHO. I'm interested in systemd-homed because we currently have no other plausible path towards encryption of user data by default [1] (since use of LUKS full-disk encryption has been rejected). [1] https://pagure.io/fedora-workstation/issue/82 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Mon, Oct 7, 2024, at 12:59 PM, Simo Sorce wrote: > What happens if I plug a disk into a laptop that sports a "homed" > directory, will the laptop suddenly allow a stranger to just login into > the machine? No, the account needs to be allowed by that machine's admin. > > What happens if there are conflicts of uid or gid ? uid/gid are recursively changed at mount time to avoid conflicts. For large homes, this could result in a lot of metadata writes. And at least on my setup with many read-only snapshots in ~/, permissions changes wouldn't be permitted, even by the root user. Some file systems have a uid= gid= mount option, but none of the ones we use for /home do. I wish this could be supported by VFS. > Will it now allow this other user to access files and directories that > should be reserved to other users? No. -- Chris Murphy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Mon, Oct 7, 2024, at 7:12 AM, Lennart Poettering wrote: > On Fr, 04.10.24 11:20, Neal Gompa (ngomp...@gmail.com) wrote: > >> > The primary purpose of systemd-homed is to use per-user encryption >> > using loopback devices. This still has various problem related to >> > resizing and suspend. Work is being done [see 3,4 for recent developments], >> > but it's not at a point where we can recommend it. >> > But systemd-homed has a mode where the user "home" is just a normal >> > directory or btrfs subvolume with some metadata stored in files [5]. >> > Some work would be needed [6] to make this work smoothly, but it >> > doesn't seem like too much. (Mostly filing down some rough edges >> > in systemd-homed and adding pam_home_systemd and nss_systemd >> > in various authselect profiles.) >> > >> > Thus the question: would this be something worth looking into? >> >> When this was first explored a few years ago, the main problem that >> came up was that homed is functionally incompatible with centralized >> login systems (SSSD to FreeIPA/AD, OIDC, etc.). If this has changed, >> then it would make sense to revisit. > > Well, you are comparing apples and oranges here. sssd/freeipa provides > some users to the system, as does the traditional /etc/passwd system, > and now homed some more. > > You should be able to combine the three sources of users freely > without problems – if you like. But these three sources of user > definitions should be on similar footing, and not try to abstract each > other. > > Hence: if you have some user in ldap/ipa, and another in homed, that's > entirely fine, they should not affect each other. Supporting local encrypted user data with centralized authentication methods is desired. Why implement this outside of systemd-homed rather than within it? The former seems like a duplicated effort. But OK, I don't know how the sd-homed key eviction feature at sleep time might work for centralized authentication. -- Chris Murphy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Sat, 2024-10-05 at 07:36 +, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Oct 04, 2024 at 12:17:14PM -0400, David Cantrell wrote: > > The common use case for this is the Fedora laptop user which in nearly every > > case is going to have one local user account. > > > > I have always split /home from the rest of the system and I know others do > > as well. I would rather see anaconda modified so that if I am creating a > > user account at install time, check for /home/USERNAME and if USERNAME > > matches and the UID and GID matches, just don't create the home directory. > > That is, -M on useradd(8). > > Yeah, that's the other possible approach. But I think it's actually > quite complicated to make this work reliably. Traditional UNIX accounts > spread the information about the user over a bunch of files. Consistency > must be maintained, UIDs and GIDs on disk must match, etc. We _could_ > add the smarts to cover all that in Anaconda, but Anaconda developers > are trying to simplify it, not add new complicated code. > > OTOH, homed was created with the idea of self-contained "homes" from > the beginning, and systemd upstream is dedicating resources to make it > work. (E.g., currently, a full-time developer working on integration > of systemd-homed and GNOME on a grant from German STF.) > So I think it's much more maintainable to just make use of this and > let systemd upstream help with any bugs that we discover. > > The homed approach would make other things possible too. For example, > sharing of /home in dual-boot scenarios. Right now a manual setup > needs to be done, and login details need to be propagated each time, > but with homed, dual-boot and reinstall are very similar scenarios, > so if we get one to work, we get the other one for free. > > Zbyszek The homed approach can work only in cases where you basically have only one user and all the OSs use the same approach. I see a few issues with security that needs to be addressed. What happens if I plug a disk into a laptop that sports a "homed" directory, will the laptop suddenly allow a stranger to just login into the machine? What happens if there are conflicts of uid or gid ? Will it now allow this other user to access files and directories that should be reserved to other users? What happen if you want to change the user to be a corporate directory provided one? Can you configure autologin for those uses cases (like kiosks or a home entertainment system) where that makes sense to do ? Is this tied to a specific file system type? Changing a default like this is not something to do lightly IMHO. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Sa, 05.10.24 05:50, Neal Gompa (ngomp...@gmail.com) wrote: > > > So from my point of view, homed *should not* be incompatible with this > > > use-case, even though it currently is. > > > > I would just use normal users for that case. This functionality is > > not going away and there would be no benefit from somehow shoehorning > > remotely-defined users into systemd-homed. > > There is: automatic encryption of user data, and tying the user-data > decryption to central login credentials. I think you want homed to be something it really isn't. It's about locally managed stuff, not about networked accounts. If you want networked stuff, thta's fine, then use sssd, but this really doesn't need to take place like this within the homed framework really. > The whole reason we explored homed was for that, and there is very > little benefit to doing any integration work for homed if we can't > universally reap the benefits of it. Well, that's a bit like saying we shouldn't adopt mysql because it is a shit web browser, no? I mean, it's true, mysql *is* a shit web browser, but it's not really what mysql is supposed to be, no? Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Fr, 04.10.24 13:20, Neal Gompa (ngomp...@gmail.com) wrote: > On Fri, Oct 4, 2024 at 11:36 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Fri, Oct 04, 2024 at 11:20:48AM -0400, Neal Gompa wrote: > > > When this was first explored a few years ago, the main problem that > > > came up was that homed is functionally incompatible with centralized > > > login systems (SSSD to FreeIPA/AD, OIDC, etc.). If this has changed, > > > then it would make sense to revisit. > > > > homed is about self-contained definitions of users. So obviously > > those users cannot be defined centrally… I think it's compatible in > > the sense that both kinds of users can be used on the same machine. > > Is there some more specific problem? > > > > It's fairly normal these days that the users are self-contained and > otherwise local, *except* for login credentials. This use-case is > important to support because this is pretty much how business laptops > need to work. > > In the long past, the dichotomy was clearer: you either had local > users with local storage, or centrally managed users with remote > storage. But nowadays it's always local storage, just with either > local authentication or remote authentication. This also includes > being able to cache remote authentication records (e.g. SSSD) for > brief offline periods for logging in anyway. > > So from my point of view, homed *should not* be incompatible with this > use-case, even though it currently is. homed is something different than sssd stuff, it's just local user management, with some nice properties. It is not in the business of centralized, enterprise user management, and that's entirely fine. glibc NSS defines a somewhat OK'ish abstraction over homed and sssd so that most apps don#t really have to care where a user comes from, from the network (i.e. sssd) or from a locally managed thing (i.e. homed). Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Пан, 07 кас 2024, Zdenek Pytela wrote: On Mon, Oct 7, 2024 at 12:36 PM Alexander Bokovoy wrote: On Няд, 06 кас 2024, Zbigniew Jędrzejewski-Szmek wrote: >On Sat, Oct 05, 2024 at 10:53:16AM +0300, Alexander Bokovoy wrote: >> Can we move systemd-homed configuration and activation into something >> that could be explicitly enabled by the administrators? Whether this is >> done during installation or post, it still would need to be a concious >> step made by admins. > >It can be enabled and disabled. Nevertheless, having it enabled seems >to e a good default. If there are no homed users defined, it should >just hang in the background doing nothing. (Though maybe it could exit >after being started. I'll try to look into this.) > >Any SELinux denials will have to be fixed anyway. So this is not an >argument for disabling it. Sure, it does need to be fixed. However, I think it is a signal that systemd-homed is not really in use across Fedora community. The original SELinux issue was opened in 2021, against Fedora 35: https://bugzilla.redhat.com/show_bug.cgi?id=2036108 Since that time multiple people tried to get SELinux policy developed and merged upstream and none happened until we re-raised its importance from OpenQA failures for FreeIPA. So SELinux policy changes would come but this is not enough. A question was raised in 2023 by mattdm about systemd-homed support of SELinux on newly created homes as somebody commented that systemd-homed does not support proper labeling of the homes: https://github.com/fedora-selinux/selinux-policy/pull/939#issuecomment-1409217811 No follow up happened on that, sadly. I do not see any work done on that yet. Without having SELinux support properly integrated, I think enabling systemd-homed by default is premature. Actually selinux-policy has support for systemd-homed in F41 and F42 since Sep 24th. Thanks, though this is about the first part (selinux-policy allowing systemd-homed to access its own default home directory), while the github comment talks about drives that systemd-homed creates for user homes. That part needs to be addressed in systemd-homed, if I understand correctly, pretty much like we address labeling of auto-created home directories in oddjob. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Fr, 04.10.24 11:20, Neal Gompa (ngomp...@gmail.com) wrote: > > The primary purpose of systemd-homed is to use per-user encryption > > using loopback devices. This still has various problem related to > > resizing and suspend. Work is being done [see 3,4 for recent developments], > > but it's not at a point where we can recommend it. > > But systemd-homed has a mode where the user "home" is just a normal > > directory or btrfs subvolume with some metadata stored in files [5]. > > Some work would be needed [6] to make this work smoothly, but it > > doesn't seem like too much. (Mostly filing down some rough edges > > in systemd-homed and adding pam_home_systemd and nss_systemd > > in various authselect profiles.) > > > > Thus the question: would this be something worth looking into? > > When this was first explored a few years ago, the main problem that > came up was that homed is functionally incompatible with centralized > login systems (SSSD to FreeIPA/AD, OIDC, etc.). If this has changed, > then it would make sense to revisit. Well, you are comparing apples and oranges here. sssd/freeipa provides some users to the system, as does the traditional /etc/passwd system, and now homed some more. You should be able to combine the three sources of users freely without problems – if you like. But these three sources of user definitions should be on similar footing, and not try to abstract each other. Hence: if you have some user in ldap/ipa, and another in homed, that's entirely fine, they should not affect each other. Lennart -- Lennart Poettering, Berlin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Mon, Oct 7, 2024 at 12:36 PM Alexander Bokovoy wrote: > On Няд, 06 кас 2024, Zbigniew Jędrzejewski-Szmek wrote: > >On Sat, Oct 05, 2024 at 10:53:16AM +0300, Alexander Bokovoy wrote: > >> Can we move systemd-homed configuration and activation into something > >> that could be explicitly enabled by the administrators? Whether this is > >> done during installation or post, it still would need to be a concious > >> step made by admins. > > > >It can be enabled and disabled. Nevertheless, having it enabled seems > >to e a good default. If there are no homed users defined, it should > >just hang in the background doing nothing. (Though maybe it could exit > >after being started. I'll try to look into this.) > > > >Any SELinux denials will have to be fixed anyway. So this is not an > >argument for disabling it. > > Sure, it does need to be fixed. However, I think it is a signal that > systemd-homed is not really in use across Fedora community. The original > SELinux issue was opened in 2021, against Fedora 35: > https://bugzilla.redhat.com/show_bug.cgi?id=2036108 > > Since that time multiple people tried to get SELinux policy developed > and merged upstream and none happened until we re-raised its importance > from OpenQA failures for FreeIPA. So SELinux policy changes would come > but this is not enough. > > A question was raised in 2023 by mattdm about systemd-homed support of > SELinux on newly created homes as somebody commented that systemd-homed > does not support proper labeling of the homes: > > https://github.com/fedora-selinux/selinux-policy/pull/939#issuecomment-1409217811 > No follow up happened on that, sadly. > > I do not see any work done on that yet. Without having SELinux support > properly integrated, I think enabling systemd-homed by default is > premature. > Actually selinux-policy has support for systemd-homed in F41 and F42 since Sep 24th. > > Could you please make sure this is addressed by systemd-homed through > upstream? > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Zdenek Pytela Security SELinux team -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Няд, 06 кас 2024, Zbigniew Jędrzejewski-Szmek wrote: On Sat, Oct 05, 2024 at 10:53:16AM +0300, Alexander Bokovoy wrote: Can we move systemd-homed configuration and activation into something that could be explicitly enabled by the administrators? Whether this is done during installation or post, it still would need to be a concious step made by admins. It can be enabled and disabled. Nevertheless, having it enabled seems to e a good default. If there are no homed users defined, it should just hang in the background doing nothing. (Though maybe it could exit after being started. I'll try to look into this.) Any SELinux denials will have to be fixed anyway. So this is not an argument for disabling it. Sure, it does need to be fixed. However, I think it is a signal that systemd-homed is not really in use across Fedora community. The original SELinux issue was opened in 2021, against Fedora 35: https://bugzilla.redhat.com/show_bug.cgi?id=2036108 Since that time multiple people tried to get SELinux policy developed and merged upstream and none happened until we re-raised its importance from OpenQA failures for FreeIPA. So SELinux policy changes would come but this is not enough. A question was raised in 2023 by mattdm about systemd-homed support of SELinux on newly created homes as somebody commented that systemd-homed does not support proper labeling of the homes: https://github.com/fedora-selinux/selinux-policy/pull/939#issuecomment-1409217811 No follow up happened on that, sadly. I do not see any work done on that yet. Without having SELinux support properly integrated, I think enabling systemd-homed by default is premature. Could you please make sure this is addressed by systemd-homed through upstream? -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Sat, Oct 05, 2024 at 10:53:16AM +0300, Alexander Bokovoy wrote: > Can we move systemd-homed configuration and activation into something > that could be explicitly enabled by the administrators? Whether this is > done during installation or post, it still would need to be a concious > step made by admins. It can be enabled and disabled. Nevertheless, having it enabled seems to e a good default. If there are no homed users defined, it should just hang in the background doing nothing. (Though maybe it could exit after being started. I'll try to look into this.) Any SELinux denials will have to be fixed anyway. So this is not an argument for disabling it. Zbyszek > Right now systemd-homed is activated on each system without ask for it, > even on systems that do not benefit from its use (see parallel > discussion by Neal). I also see it as a sole contributor to SELinux AVCs > in OpenQA tests we run for FreeIPA use cases. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Sat, Oct 5, 2024 at 3:45 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Oct 04, 2024 at 01:20:40PM -0400, Neal Gompa wrote: > > It's fairly normal these days that the users are self-contained and > > otherwise local, *except* for login credentials. This use-case is > > important to support because this is pretty much how business laptops > > need to work. > > > > In the long past, the dichotomy was clearer: you either had local > > users with local storage, or centrally managed users with remote > > storage. But nowadays it's always local storage, just with either > > local authentication or remote authentication. This also includes > > being able to cache remote authentication records (e.g. SSSD) for > > brief offline periods for logging in anyway. > > > > So from my point of view, homed *should not* be incompatible with this > > use-case, even though it currently is. > > I would just use normal users for that case. This functionality is > not going away and there would be no benefit from somehow shoehorning > remotely-defined users into systemd-homed. > There is: automatic encryption of user data, and tying the user-data decryption to central login credentials. The whole reason we explored homed was for that, and there is very little benefit to doing any integration work for homed if we can't universally reap the benefits of it. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Суб, 05 кас 2024, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Oct 04, 2024 at 12:17:14PM -0400, David Cantrell wrote: The common use case for this is the Fedora laptop user which in nearly every case is going to have one local user account. I have always split /home from the rest of the system and I know others do as well. I would rather see anaconda modified so that if I am creating a user account at install time, check for /home/USERNAME and if USERNAME matches and the UID and GID matches, just don't create the home directory. That is, -M on useradd(8). Yeah, that's the other possible approach. But I think it's actually quite complicated to make this work reliably. Traditional UNIX accounts spread the information about the user over a bunch of files. Consistency must be maintained, UIDs and GIDs on disk must match, etc. We _could_ add the smarts to cover all that in Anaconda, but Anaconda developers are trying to simplify it, not add new complicated code. OTOH, homed was created with the idea of self-contained "homes" from the beginning, and systemd upstream is dedicating resources to make it work. (E.g., currently, a full-time developer working on integration of systemd-homed and GNOME on a grant from German STF.) So I think it's much more maintainable to just make use of this and let systemd upstream help with any bugs that we discover. The homed approach would make other things possible too. For example, sharing of /home in dual-boot scenarios. Right now a manual setup needs to be done, and login details need to be propagated each time, but with homed, dual-boot and reinstall are very similar scenarios, so if we get one to work, we get the other one for free. Can we move systemd-homed configuration and activation into something that could be explicitly enabled by the administrators? Whether this is done during installation or post, it still would need to be a concious step made by admins. Right now systemd-homed is activated on each system without ask for it, even on systems that do not benefit from its use (see parallel discussion by Neal). I also see it as a sole contributor to SELinux AVCs in OpenQA tests we run for FreeIPA use cases. It would be best to have it explicitly enabled by admins, similarly how authselect handles various authentication methods. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Fri, Oct 04, 2024 at 01:20:40PM -0400, Neal Gompa wrote: > It's fairly normal these days that the users are self-contained and > otherwise local, *except* for login credentials. This use-case is > important to support because this is pretty much how business laptops > need to work. > > In the long past, the dichotomy was clearer: you either had local > users with local storage, or centrally managed users with remote > storage. But nowadays it's always local storage, just with either > local authentication or remote authentication. This also includes > being able to cache remote authentication records (e.g. SSSD) for > brief offline periods for logging in anyway. > > So from my point of view, homed *should not* be incompatible with this > use-case, even though it currently is. I would just use normal users for that case. This functionality is not going away and there would be no benefit from somehow shoehorning remotely-defined users into systemd-homed. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Fri, Oct 04, 2024 at 12:17:14PM -0400, David Cantrell wrote: > The common use case for this is the Fedora laptop user which in nearly every > case is going to have one local user account. > > I have always split /home from the rest of the system and I know others do > as well. I would rather see anaconda modified so that if I am creating a > user account at install time, check for /home/USERNAME and if USERNAME > matches and the UID and GID matches, just don't create the home directory. > That is, -M on useradd(8). Yeah, that's the other possible approach. But I think it's actually quite complicated to make this work reliably. Traditional UNIX accounts spread the information about the user over a bunch of files. Consistency must be maintained, UIDs and GIDs on disk must match, etc. We _could_ add the smarts to cover all that in Anaconda, but Anaconda developers are trying to simplify it, not add new complicated code. OTOH, homed was created with the idea of self-contained "homes" from the beginning, and systemd upstream is dedicating resources to make it work. (E.g., currently, a full-time developer working on integration of systemd-homed and GNOME on a grant from German STF.) So I think it's much more maintainable to just make use of this and let systemd upstream help with any bugs that we discover. The homed approach would make other things possible too. For example, sharing of /home in dual-boot scenarios. Right now a manual setup needs to be done, and login details need to be propagated each time, but with homed, dual-boot and reinstall are very similar scenarios, so if we get one to work, we get the other one for free. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Fri, Oct 4, 2024 at 11:36 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Oct 04, 2024 at 11:20:48AM -0400, Neal Gompa wrote: > > When this was first explored a few years ago, the main problem that > > came up was that homed is functionally incompatible with centralized > > login systems (SSSD to FreeIPA/AD, OIDC, etc.). If this has changed, > > then it would make sense to revisit. > > homed is about self-contained definitions of users. So obviously > those users cannot be defined centrally… I think it's compatible in > the sense that both kinds of users can be used on the same machine. > Is there some more specific problem? > It's fairly normal these days that the users are self-contained and otherwise local, *except* for login credentials. This use-case is important to support because this is pretty much how business laptops need to work. In the long past, the dichotomy was clearer: you either had local users with local storage, or centrally managed users with remote storage. But nowadays it's always local storage, just with either local authentication or remote authentication. This also includes being able to cache remote authentication records (e.g. SSSD) for brief offline periods for logging in anyway. So from my point of view, homed *should not* be incompatible with this use-case, even though it currently is. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On 10/4/24 11:05, Zbigniew Jędrzejewski-Szmek wrote: Hi folks, I was recently doing a bunch of test reinstalls of Fedora [1], looking to see if it's complicated to retain the user directories during a reinstall. The answer is, sadly, that it's possible only with some manual tinkering. This is a known problem [2]. With a little bit of trickery, Anaconda will let the "home" subvolume be and install the system to a new "root" subvolume, so user data is preserved. But then after a reboot a new user will be created, because the old user is not hooked up into /etc/passwd. We actually have a partial solution for this: systemd-homed. With systemd-homed the information about the user is maintained in the user directory/subvolume/partition, e.g. /home/username.homedir. After a reinstall, ideally nothing needs to be done and the user account is ready to be used. The primary purpose of systemd-homed is to use per-user encryption using loopback devices. This still has various problem related to resizing and suspend. Work is being done [see 3,4 for recent developments], but it's not at a point where we can recommend it. But systemd-homed has a mode where the user "home" is just a normal directory or btrfs subvolume with some metadata stored in files [5]. Some work would be needed [6] to make this work smoothly, but it doesn't seem like too much. (Mostly filing down some rough edges in systemd-homed and adding pam_home_systemd and nss_systemd in various authselect profiles.) Thus the question: would this be something worth looking into? [1] https://discussion.fedoraproject.org/t/feedback-anaconda-web-ui-partitioning/108995/65 [2] https://discussion.fedoraproject.org/t/its-difficult-to-reformat-a-btrfs-partition-subvolume-in-the-installer/89052 [3] https://cfp.all-systems-go.io/all-systems-go-2024/talk/FFY3BB/ [4] https://www.youtube.com/watch?v=3e3IhBBU0JY [5] https://systemd.io/HOME_DIRECTORY/ [6] When I tested this today, this actually doesn't work. systemd-homed does a misguided check that break reinstalls. We'd need to figure out some solution here. Most likely just conditionalize that part of the code. Zbyszek The common use case for this is the Fedora laptop user which in nearly every case is going to have one local user account. I have always split /home from the rest of the system and I know others do as well. I would rather see anaconda modified so that if I am creating a user account at install time, check for /home/USERNAME and if USERNAME matches and the UID and GID matches, just don't create the home directory. That is, -M on useradd(8). -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Fri, Oct 04, 2024 at 11:20:48AM -0400, Neal Gompa wrote: > When this was first explored a few years ago, the main problem that > came up was that homed is functionally incompatible with centralized > login systems (SSSD to FreeIPA/AD, OIDC, etc.). If this has changed, > then it would make sense to revisit. homed is about self-contained definitions of users. So obviously those users cannot be defined centrally… I think it's compatible in the sense that both kinds of users can be used on the same machine. Is there some more specific problem? Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: strawman proposal: homed directories for users
On Fri, Oct 4, 2024 at 11:05 AM Zbigniew Jędrzejewski-Szmek wrote: > > Hi folks, > > I was recently doing a bunch of test reinstalls of Fedora [1], > looking to see if it's complicated to retain the user directories > during a reinstall. The answer is, sadly, that it's possible only with > some manual tinkering. This is a known problem [2]. > > With a little bit of trickery, Anaconda will let the "home" subvolume > be and install the system to a new "root" subvolume, so user data is > preserved. But then after a reboot a new user will be created, because > the old user is not hooked up into /etc/passwd. > > We actually have a partial solution for this: systemd-homed. > With systemd-homed the information about the user is maintained in the > user directory/subvolume/partition, e.g. /home/username.homedir. > After a reinstall, ideally nothing needs to be done and the user > account is ready to be used. > > The primary purpose of systemd-homed is to use per-user encryption > using loopback devices. This still has various problem related to > resizing and suspend. Work is being done [see 3,4 for recent developments], > but it's not at a point where we can recommend it. > But systemd-homed has a mode where the user "home" is just a normal > directory or btrfs subvolume with some metadata stored in files [5]. > Some work would be needed [6] to make this work smoothly, but it > doesn't seem like too much. (Mostly filing down some rough edges > in systemd-homed and adding pam_home_systemd and nss_systemd > in various authselect profiles.) > > Thus the question: would this be something worth looking into? > When this was first explored a few years ago, the main problem that came up was that homed is functionally incompatible with centralized login systems (SSSD to FreeIPA/AD, OIDC, etc.). If this has changed, then it would make sense to revisit. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
