| Message ID | 20211127164549.2571457-2-James.Bottomley@HansenPartnership.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Namespace IMA | expand |
On Sat, Nov 27, 2021 at 04:45:47PM +0000, James Bottomley wrote: > As a precursor to namespacing IMA a way of uniquely identifying the > namespace to appear in the IMA log is needed. This log may be > transported away from the running system and may be analyzed even > after the system has been rebooted. Thus we need a way of identifying > namespaces in the log which is unique. UUID, being designed > probabilistically never to repeat, fits this bill so add it to the > user_namespace which we'll also use for namespacing IMA. If the logs run across 5 boots, is it important to you that the uuid be unique across all 5 boots? Would it suffice to have a per-boot unique count and report that plus some indicator of the current boot (like boot time in jiffies)?
On Sat, 2021-11-27 at 22:45 -0600, Serge E. Hallyn wrote: > On Sat, Nov 27, 2021 at 04:45:47PM +0000, James Bottomley wrote: > > As a precursor to namespacing IMA a way of uniquely identifying the > > namespace to appear in the IMA log is needed. This log may be > > transported away from the running system and may be analyzed even > > after the system has been rebooted. Thus we need a way of > > identifying namespaces in the log which is unique. UUID, being > > designed probabilistically never to repeat, fits this bill so add > > it to the user_namespace which we'll also use for namespacing IMA. > > If the logs run across 5 boots, is it important to you that the > uuid be unique across all 5 boots? Would it suffice to have a > per-boot unique count and report that plus some indicator of the > current boot (like boot time in jiffies)? For the purposes of IMA it's only really important to have the uuid be unique within the particular log ... i.e. unique per boot. However, given the prevalence of uuids elsewhere and the fact we have no current per-boot unique label for the namespace (the inode number could repeat), it seemed reasonable to employ uuids for this rather than invent a different identifier. Plus IMA isn't going to complain if we have a globally unique identifier ... James
On Sun, Nov 28, 2021 at 08:29:21AM -0500, James Bottomley wrote: > On Sat, 2021-11-27 at 22:45 -0600, Serge E. Hallyn wrote: > > On Sat, Nov 27, 2021 at 04:45:47PM +0000, James Bottomley wrote: > > > As a precursor to namespacing IMA a way of uniquely identifying the > > > namespace to appear in the IMA log is needed. This log may be > > > transported away from the running system and may be analyzed even > > > after the system has been rebooted. Thus we need a way of > > > identifying namespaces in the log which is unique. UUID, being > > > designed probabilistically never to repeat, fits this bill so add > > > it to the user_namespace which we'll also use for namespacing IMA. > > > > If the logs run across 5 boots, is it important to you that the > > uuid be unique across all 5 boots? Would it suffice to have a > > per-boot unique count and report that plus some indicator of the > > current boot (like boot time in jiffies)? > > For the purposes of IMA it's only really important to have the uuid be > unique within the particular log ... i.e. unique per boot. However, > given the prevalence of uuids elsewhere and the fact we have no current > per-boot unique label for the namespace (the inode number could > repeat), it seemed reasonable to employ uuids for this rather than > invent a different identifier. Plus IMA isn't going to complain if we > have a globally unique identifier ... Ok - Note I'm not saying I heavily object, but I'm mildly concerned about users who happen to spin off a lot of user namespaces for quick jobs being penalized. I suspect Eric will also worry about the namespacing implications - i.e. people *will* want to start restoring user namespaces with a previously used uuid. So given that 'unique per boot' is sufficient, what would be the problem with simply adding a simple ever-increasing unique atomix count to the struct user_namespace? -serge
On Sun, 2021-11-28 at 09:18 -0600, Serge E. Hallyn wrote: > On Sun, Nov 28, 2021 at 08:29:21AM -0500, James Bottomley wrote: > > On Sat, 2021-11-27 at 22:45 -0600, Serge E. Hallyn wrote: > > > On Sat, Nov 27, 2021 at 04:45:47PM +0000, James Bottomley wrote: > > > > As a precursor to namespacing IMA a way of uniquely identifying > > > > the namespace to appear in the IMA log is needed. This log may > > > > be transported away from the running system and may be analyzed > > > > even after the system has been rebooted. Thus we need a way of > > > > identifying namespaces in the log which is unique. UUID, being > > > > designed probabilistically never to repeat, fits this bill so > > > > add it to the user_namespace which we'll also use for > > > > namespacing IMA. > > > > > > If the logs run across 5 boots, is it important to you that the > > > uuid be unique across all 5 boots? Would it suffice to have a > > > per-boot unique count and report that plus some indicator of the > > > current boot (like boot time in jiffies)? > > > > For the purposes of IMA it's only really important to have the uuid > > be unique within the particular log ... i.e. unique per > > boot. However, given the prevalence of uuids elsewhere and the > > fact we have no current per-boot unique label for the namespace > > (the inode number could repeat), it seemed reasonable to employ > > uuids for this rather than invent a different identifier. Plus IMA > > isn't going to complain if we have a globally unique identifier ... > > Ok - Note I'm not saying I heavily object, but I'm mildly concerned > about users who happen to spin off a lot of user namespaces for > quick jobs being penalized. Well, that's why I use the uuid_gen coupled to prandom ... there shouldn't be a measurable overhead generating it. > I suspect Eric will also worry about the namespacing implications - > i.e. people *will* want to start restoring user namespaces with a > previously used uuid. So this is a problem I tried to address in the last paragraph. If I put any marker on a namespace, people are potentially going to want to save and restore it. The bottom line is that ima logs are add only. You can't save and restore them so we're already dealing with something that can't be CRIU transported. I had hoped that it would be obvious that a randomly generated uuid, whose uniqueness depends on random generation likewise can't be saved and restored because we'd have no way to prevent a clash. > So given that 'unique per boot' is sufficient, what would be the > problem with simply adding a simple ever-increasing unique atomix > count to the struct user_namespace? I don't think there is any ... but I equally don't see why people would want to save and restore the uuid but not the new monotonic identifier ... because it's still just a marker on a namespace. James
On Sun, Nov 28, 2021 at 01:00:28PM -0500, James Bottomley wrote: > On Sun, 2021-11-28 at 09:18 -0600, Serge E. Hallyn wrote: > > On Sun, Nov 28, 2021 at 08:29:21AM -0500, James Bottomley wrote: > > > On Sat, 2021-11-27 at 22:45 -0600, Serge E. Hallyn wrote: > > > > On Sat, Nov 27, 2021 at 04:45:47PM +0000, James Bottomley wrote: > > > > > As a precursor to namespacing IMA a way of uniquely identifying > > > > > the namespace to appear in the IMA log is needed. This log may > > > > > be transported away from the running system and may be analyzed > > > > > even after the system has been rebooted. Thus we need a way of > > > > > identifying namespaces in the log which is unique. UUID, being > > > > > designed probabilistically never to repeat, fits this bill so > > > > > add it to the user_namespace which we'll also use for > > > > > namespacing IMA. > > > > > > > > If the logs run across 5 boots, is it important to you that the > > > > uuid be unique across all 5 boots? Would it suffice to have a > > > > per-boot unique count and report that plus some indicator of the > > > > current boot (like boot time in jiffies)? > > > > > > For the purposes of IMA it's only really important to have the uuid > > > be unique within the particular log ... i.e. unique per > > > boot. However, given the prevalence of uuids elsewhere and the > > > fact we have no current per-boot unique label for the namespace > > > (the inode number could repeat), it seemed reasonable to employ > > > uuids for this rather than invent a different identifier. Plus IMA > > > isn't going to complain if we have a globally unique identifier ... > > > > Ok - Note I'm not saying I heavily object, but I'm mildly concerned > > about users who happen to spin off a lot of user namespaces for > > quick jobs being penalized. > > Well, that's why I use the uuid_gen coupled to prandom ... there > shouldn't be a measurable overhead generating it. Does prandom have *no*, or just little effect on the entopy pool? Tried briefly looking at prandom_u32, not quite getting how it's using net_rand_state - it reads it and uses it but doesn't make any changes to it? > > I suspect Eric will also worry about the namespacing implications - > > i.e. people *will* want to start restoring user namespaces with a > > previously used uuid. > > So this is a problem I tried to address in the last paragraph. If I > put any marker on a namespace, people are potentially going to want to > save and restore it. The bottom line is that ima logs are add only. > You can't save and restore them so we're already dealing with something > that can't be CRIU transported. I had hoped that it would be obvious > that a randomly generated uuid, whose uniqueness depends on random > generation likewise can't be saved and restored because we'd have no > way to prevent a clash. Yes but you're making this a general user_namespace struct member. So once that's there people will want to export it, use it for things other than ima. > > So given that 'unique per boot' is sufficient, what would be the > > problem with simply adding a simple ever-increasing unique atomix > > count to the struct user_namespace? > > I don't think there is any ... but I equally don't see why people would > want to save and restore the uuid but not the new monotonic identifier > ... because it's still just a marker on a namespace. But you've called it "the namespace uuid". I'm not even really thinking of checkpoint/restart, just stopping and restarting a container. I'm convinced people will want to start using it because, well, it is a nice feature. -serge
On Sun, 2021-11-28 at 14:47 -0600, Serge E. Hallyn wrote: > On Sun, Nov 28, 2021 at 01:00:28PM -0500, James Bottomley wrote: > > On Sun, 2021-11-28 at 09:18 -0600, Serge E. Hallyn wrote: > > > On Sun, Nov 28, 2021 at 08:29:21AM -0500, James Bottomley wrote: > > > > On Sat, 2021-11-27 at 22:45 -0600, Serge E. Hallyn wrote: > > > > > On Sat, Nov 27, 2021 at 04:45:47PM +0000, James Bottomley > > > > > wrote: > > > > > > As a precursor to namespacing IMA a way of uniquely > > > > > > identifying the namespace to appear in the IMA log is > > > > > > needed. This log may be transported away from the running > > > > > > system and may be analyzed even after the system has been > > > > > > rebooted. Thus we need a way of identifying namespaces in > > > > > > the log which is unique. UUID, being designed > > > > > > probabilistically never to repeat, fits this bill > > > > > > so add it to the user_namespace which we'll also use for > > > > > > namespacing IMA. > > > > > > > > > > If the logs run across 5 boots, is it important to you that > > > > > the uuid be unique across all 5 boots? Would it suffice to > > > > > have a per-boot unique count and report that plus some > > > > > indicator of the current boot (like boot time in jiffies)? > > > > > > > > For the purposes of IMA it's only really important to have the > > > > uuid be unique within the particular log ... i.e. unique per > > > > boot. However, given the prevalence of uuids elsewhere and the > > > > fact we have no current per-boot unique label for the namespace > > > > (the inode number could repeat), it seemed reasonable to employ > > > > uuids for this rather than invent a different identifier. Plus > > > > IMA isn't going to complain if we have a globally unique > > > > identifier > > > > ... > > > > > > Ok - Note I'm not saying I heavily object, but I'm mildly > > > concerned about users who happen to spin off a lot of user > > > namespaces for quick jobs being penalized. > > > > Well, that's why I use the uuid_gen coupled to prandom ... there > > shouldn't be a measurable overhead generating it. > > Does prandom have *no*, or just little effect on the entopy pool? > Tried briefly looking at prandom_u32, not quite getting how it's > using net_rand_state - it reads it and uses it but doesn't make > any changes to it? It has a first use effect to get the seed but once that happens it has no further effect on the entropy pool. > > > I suspect Eric will also worry about the namespacing > > > implications - i.e. people *will* want to start restoring user > > > namespaces with a previously used uuid. > > > > So this is a problem I tried to address in the last paragraph. If > > I put any marker on a namespace, people are potentially going to > > want to save and restore it. The bottom line is that ima logs are > > add only. You can't save and restore them so we're already dealing > > with something that can't be CRIU transported. I had hoped that it > > would be obvious that a randomly generated uuid, whose uniqueness > > depends on random generation likewise can't be saved and restored > > because we'd have no way to prevent a clash. > > Yes but you're making this a general user_namespace struct member. > So once that's there people will want to export it, use it for > things other than ima. Yes, that's why I did it. However, the property of uniqueness for all uuid type things depends on randomness, so ipso facto, they can never be settable. > > > So given that 'unique per boot' is sufficient, what would be the > > > problem with simply adding a simple ever-increasing unique atomix > > > count to the struct user_namespace? > > > > I don't think there is any ... but I equally don't see why people > > would want to save and restore the uuid but not the new monotonic > > identifier ... because it's still just a marker on a namespace. > > But you've called it "the namespace uuid". I'm not even really > thinking of checkpoint/restart, just stopping and restarting a > container. I'm convinced people will want to start using it because, > well, it is a nice feature. Right, but the uniqueness property depends on you not being able to set it. If you just want a namespace label, you can have that, but anything a user can set is either a pain to guarantee uniqueness (have to check all the other objects) or is simply a non-unique label. If you want to label a container, which could have many namespaces and be stopped and restarted many times, it does sound like you want a non- unique settable label. However, IMA definitely needs a guaranteed per namespace unique label. Is the objection simply you think a UUID sound like it should be settable and a monotonic counter sounds like it shouldn't? Because to me (coming I suppose from dealing with uuids in edk2) neither sounds like it should be settable. James
On Sun, Nov 28, 2021 at 04:21:29PM -0500, James Bottomley wrote: > On Sun, 2021-11-28 at 14:47 -0600, Serge E. Hallyn wrote: > > On Sun, Nov 28, 2021 at 01:00:28PM -0500, James Bottomley wrote: > > > On Sun, 2021-11-28 at 09:18 -0600, Serge E. Hallyn wrote: > > > > On Sun, Nov 28, 2021 at 08:29:21AM -0500, James Bottomley wrote: > > > > > On Sat, 2021-11-27 at 22:45 -0600, Serge E. Hallyn wrote: > > > > > > On Sat, Nov 27, 2021 at 04:45:47PM +0000, James Bottomley > > > > > > wrote: > > > > > > > As a precursor to namespacing IMA a way of uniquely > > > > > > > identifying the namespace to appear in the IMA log is > > > > > > > needed. This log may be transported away from the running > > > > > > > system and may be analyzed even after the system has been > > > > > > > rebooted. Thus we need a way of identifying namespaces in > > > > > > > the log which is unique. UUID, being designed > > > > > > > probabilistically never to repeat, fits this bill > > > > > > > so add it to the user_namespace which we'll also use for > > > > > > > namespacing IMA. > > > > > > > > > > > > If the logs run across 5 boots, is it important to you that > > > > > > the uuid be unique across all 5 boots? Would it suffice to > > > > > > have a per-boot unique count and report that plus some > > > > > > indicator of the current boot (like boot time in jiffies)? > > > > > > > > > > For the purposes of IMA it's only really important to have the > > > > > uuid be unique within the particular log ... i.e. unique per > > > > > boot. However, given the prevalence of uuids elsewhere and the > > > > > fact we have no current per-boot unique label for the namespace > > > > > (the inode number could repeat), it seemed reasonable to employ > > > > > uuids for this rather than invent a different identifier. Plus > > > > > IMA isn't going to complain if we have a globally unique > > > > > identifier > > > > > ... > > > > > > > > Ok - Note I'm not saying I heavily object, but I'm mildly > > > > concerned about users who happen to spin off a lot of user > > > > namespaces for quick jobs being penalized. > > > > > > Well, that's why I use the uuid_gen coupled to prandom ... there > > > shouldn't be a measurable overhead generating it. > > > > Does prandom have *no*, or just little effect on the entopy pool? > > Tried briefly looking at prandom_u32, not quite getting how it's > > using net_rand_state - it reads it and uses it but doesn't make > > any changes to it? > > It has a first use effect to get the seed but once that happens it has > no further effect on the entropy pool. Gotcha - thanks. > > > > I suspect Eric will also worry about the namespacing > > > > implications - i.e. people *will* want to start restoring user > > > > namespaces with a previously used uuid. > > > > > > So this is a problem I tried to address in the last paragraph. If > > > I put any marker on a namespace, people are potentially going to > > > want to save and restore it. The bottom line is that ima logs are > > > add only. You can't save and restore them so we're already dealing > > > with something that can't be CRIU transported. I had hoped that it > > > would be obvious that a randomly generated uuid, whose uniqueness > > > depends on random generation likewise can't be saved and restored > > > because we'd have no way to prevent a clash. > > > > Yes but you're making this a general user_namespace struct member. > > So once that's there people will want to export it, use it for > > things other than ima. > > Yes, that's why I did it. However, the property of uniqueness for all > uuid type things depends on randomness, so ipso facto, they can never > be settable. > > > > > So given that 'unique per boot' is sufficient, what would be the > > > > problem with simply adding a simple ever-increasing unique atomix > > > > count to the struct user_namespace? > > > > > > I don't think there is any ... but I equally don't see why people > > > would want to save and restore the uuid but not the new monotonic > > > identifier ... because it's still just a marker on a namespace. > > > > But you've called it "the namespace uuid". I'm not even really > > thinking of checkpoint/restart, just stopping and restarting a > > container. I'm convinced people will want to start using it because, > > well, it is a nice feature. > > Right, but the uniqueness property depends on you not being able to set > it. If you just want a namespace label, you can have that, but > anything a user can set is either a pain to guarantee uniqueness (have > to check all the other objects) or is simply a non-unique label. > > If you want to label a container, which could have many namespaces and > be stopped and restarted many times, it does sound like you want a non- > unique settable label. However, IMA definitely needs a guaranteed per > namespace unique label. > > Is the objection simply you think a UUID sound like it should be Objection is too strong. Concern. But yes, to me a uuid (a) feels like it should be generally useful including being settable and (b) not super duper 100% absolutely guaranteed to always be unique per boot, as an incremented counter would be. > settable and a monotonic counter sounds like it shouldn't? Because to > me (coming I suppose from dealing with uuids in edk2) neither sounds > like it should be settable. Huh - yes, in contrast, for virtualization based tests of secureboot and fs-y things we do indeed always set the uuids. -serge
On Sun, 2021-11-28 at 15:49 -0600, Serge E. Hallyn wrote: > On Sun, Nov 28, 2021 at 04:21:29PM -0500, James Bottomley wrote: > > On Sun, 2021-11-28 at 14:47 -0600, Serge E. Hallyn wrote: > > > On Sun, Nov 28, 2021 at 01:00:28PM -0500, James Bottomley wrote: > > > > On Sun, 2021-11-28 at 09:18 -0600, Serge E. Hallyn wrote: [...] > > > > > So given that 'unique per boot' is sufficient, what would be > > > > > the problem with simply adding a simple ever-increasing > > > > > unique atomix count to the struct user_namespace? > > > > > > > > I don't think there is any ... but I equally don't see why > > > > people would want to save and restore the uuid but not the new > > > > monotonic identifier ... because it's still just a marker on a > > > > namespace. > > > > > > But you've called it "the namespace uuid". I'm not even really > > > thinking of checkpoint/restart, just stopping and restarting a > > > container. I'm convinced people will want to start using it > > > because, well, it is a nice feature. > > > > Right, but the uniqueness property depends on you not being able to > > set it. If you just want a namespace label, you can have that, but > > anything a user can set is either a pain to guarantee uniqueness > > (have to check all the other objects) or is simply a non-unique > > label. > > > > If you want to label a container, which could have many namespaces > > and be stopped and restarted many times, it does sound like you > > want a non-unique settable label. However, IMA definitely needs a > > guaranteed per namespace unique label. > > > > Is the objection simply you think a UUID sound like it should be > > Objection is too strong. Concern. > > But yes, to me a uuid (a) feels like it should be generally useful > including being settable and (b) not super duper 100% absolutely > guaranteed to always be unique per boot, as an incremented counter > would be. OK, but a bunch of cats I found on the Internet agree with me, a UUID shouldn't be settable: https://en.wikipedia.org/wiki/Universally_unique_identifier The key point being, if you can set the id, it can't be unique ... it doesn't have to be random (some of the versions are time or other unique object based properties) but it does have to be derived by something that gives reasonably reliable uniqueness (which is why humans aren't allowed to set them ... we're bad a choosing unique labels). > > settable and a monotonic counter sounds like it shouldn't? Because > > to me (coming I suppose from dealing with uuids in edk2) neither > > sounds like it should be settable. > > Huh - yes, in contrast, for virtualization based tests of secureboot > and fs-y things we do indeed always set the uuids. Well, the old msdos label had a settable ID that often caused problems because it wasn't unique. The new gpt partition label specifically doesn't allow you to set the GUID label because it should be unique: https://en.wikipedia.org/wiki/GUID_Partition_Table I think some of the tools have emergency modes where you can set the label "just in case" but they shouldn't The point is that if you're using a settable uuid for containers, you're doing the wrong thing ... it should either be a non-unique label (in which case why not make it more human readable) or only the system should be allowed to set it using the prescribed algorithm. James
On Sun, Nov 28, 2021 at 05:56:28PM -0500, James Bottomley wrote: > On Sun, 2021-11-28 at 15:49 -0600, Serge E. Hallyn wrote: > > On Sun, Nov 28, 2021 at 04:21:29PM -0500, James Bottomley wrote: > > > On Sun, 2021-11-28 at 14:47 -0600, Serge E. Hallyn wrote: > > > > On Sun, Nov 28, 2021 at 01:00:28PM -0500, James Bottomley wrote: > > > > > On Sun, 2021-11-28 at 09:18 -0600, Serge E. Hallyn wrote: > [...] > > > > > > So given that 'unique per boot' is sufficient, what would be > > > > > > the problem with simply adding a simple ever-increasing > > > > > > unique atomix count to the struct user_namespace? > > > > > > > > > > I don't think there is any ... but I equally don't see why > > > > > people would want to save and restore the uuid but not the new > > > > > monotonic identifier ... because it's still just a marker on a > > > > > namespace. > > > > > > > > But you've called it "the namespace uuid". I'm not even really > > > > thinking of checkpoint/restart, just stopping and restarting a > > > > container. I'm convinced people will want to start using it > > > > because, well, it is a nice feature. > > > > > > Right, but the uniqueness property depends on you not being able to > > > set it. If you just want a namespace label, you can have that, but > > > anything a user can set is either a pain to guarantee uniqueness > > > (have to check all the other objects) or is simply a non-unique > > > label. > > > > > > If you want to label a container, which could have many namespaces > > > and be stopped and restarted many times, it does sound like you > > > want a non-unique settable label. However, IMA definitely needs a > > > guaranteed per namespace unique label. > > > > > > Is the objection simply you think a UUID sound like it should be > > > > Objection is too strong. Concern. > > > > But yes, to me a uuid (a) feels like it should be generally useful > > including being settable and (b) not super duper 100% absolutely > > guaranteed to always be unique per boot, as an incremented counter > > would be. > > OK, but a bunch of cats I found on the Internet agree with me, a UUID > shouldn't be settable: > > https://en.wikipedia.org/wiki/Universally_unique_identifier > > The key point being, if you can set the id, it can't be unique ... it Ok, so can you just put a comment above there saying "this must not be settable from userspace" ? > doesn't have to be random (some of the versions are time or other > unique object based properties) but it does have to be derived by > something that gives reasonably reliable uniqueness (which is why > humans aren't allowed to set them ... we're bad a choosing unique > labels). > > > > settable and a monotonic counter sounds like it shouldn't? Because > > > to me (coming I suppose from dealing with uuids in edk2) neither > > > sounds like it should be settable. > > > > Huh - yes, in contrast, for virtualization based tests of secureboot > > and fs-y things we do indeed always set the uuids. > > Well, the old msdos label had a settable ID that often caused problems > because it wasn't unique. The new gpt partition label specifically > doesn't allow you to set the GUID label because it should be unique: > > https://en.wikipedia.org/wiki/GUID_Partition_Table > > I think some of the tools have emergency modes where you can set the > label "just in case" but they shouldn't > > The point is that if you're using a settable uuid for containers, > you're doing the wrong thing ... it should either be a non-unique label > (in which case why not make it more human readable) or only the system > should be allowed to set it using the prescribed algorithm. It seems to me you're confuddling things to make a point. You want noone to use things that look like uuids for things where they choose the uuid - yet there are many places today where that's being done. Even the partition types: https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs C12A7328-F81F-11D2-BA4B-00A0C93EC93B was chosen for the EFI partition, and you must "set" the partition type to that. So it's set-able. Anyway I'm still not seeing what using uuids buys you over using a counter, but I'll stop debating it and look at the rest of the set. thanks, -serge
On Sun, Nov 28, 2021 at 03:49:06PM -0600, Serge Hallyn wrote: > On Sun, Nov 28, 2021 at 04:21:29PM -0500, James Bottomley wrote: > > On Sun, 2021-11-28 at 14:47 -0600, Serge E. Hallyn wrote: > > > On Sun, Nov 28, 2021 at 01:00:28PM -0500, James Bottomley wrote: > > > > On Sun, 2021-11-28 at 09:18 -0600, Serge E. Hallyn wrote: > > > > > On Sun, Nov 28, 2021 at 08:29:21AM -0500, James Bottomley wrote: > > > > > > On Sat, 2021-11-27 at 22:45 -0600, Serge E. Hallyn wrote: > > > > > > > On Sat, Nov 27, 2021 at 04:45:47PM +0000, James Bottomley > > > > > > > wrote: > > > > > > > > As a precursor to namespacing IMA a way of uniquely > > > > > > > > identifying the namespace to appear in the IMA log is > > > > > > > > needed. This log may be transported away from the running > > > > > > > > system and may be analyzed even after the system has been > > > > > > > > rebooted. Thus we need a way of identifying namespaces in > > > > > > > > the log which is unique. UUID, being designed > > > > > > > > probabilistically never to repeat, fits this bill > > > > > > > > so add it to the user_namespace which we'll also use for > > > > > > > > namespacing IMA. > > > > > > > > > > > > > > If the logs run across 5 boots, is it important to you that > > > > > > > the uuid be unique across all 5 boots? Would it suffice to > > > > > > > have a per-boot unique count and report that plus some > > > > > > > indicator of the current boot (like boot time in jiffies)? > > > > > > > > > > > > For the purposes of IMA it's only really important to have the > > > > > > uuid be unique within the particular log ... i.e. unique per > > > > > > boot. However, given the prevalence of uuids elsewhere and the > > > > > > fact we have no current per-boot unique label for the namespace > > > > > > (the inode number could repeat), it seemed reasonable to employ > > > > > > uuids for this rather than invent a different identifier. Plus > > > > > > IMA isn't going to complain if we have a globally unique > > > > > > identifier > > > > > > ... > > > > > > > > > > Ok - Note I'm not saying I heavily object, but I'm mildly > > > > > concerned about users who happen to spin off a lot of user > > > > > namespaces for quick jobs being penalized. > > > > > > > > Well, that's why I use the uuid_gen coupled to prandom ... there > > > > shouldn't be a measurable overhead generating it. > > > > > > Does prandom have *no*, or just little effect on the entopy pool? > > > Tried briefly looking at prandom_u32, not quite getting how it's > > > using net_rand_state - it reads it and uses it but doesn't make > > > any changes to it? > > > > It has a first use effect to get the seed but once that happens it has > > no further effect on the entropy pool. > > Gotcha - thanks. > > > > > > I suspect Eric will also worry about the namespacing > > > > > implications - i.e. people *will* want to start restoring user > > > > > namespaces with a previously used uuid. > > > > > > > > So this is a problem I tried to address in the last paragraph. If > > > > I put any marker on a namespace, people are potentially going to > > > > want to save and restore it. The bottom line is that ima logs are > > > > add only. You can't save and restore them so we're already dealing > > > > with something that can't be CRIU transported. I had hoped that it > > > > would be obvious that a randomly generated uuid, whose uniqueness > > > > depends on random generation likewise can't be saved and restored > > > > because we'd have no way to prevent a clash. > > > > > > Yes but you're making this a general user_namespace struct member. > > > So once that's there people will want to export it, use it for > > > things other than ima. > > > > Yes, that's why I did it. However, the property of uniqueness for all > > uuid type things depends on randomness, so ipso facto, they can never > > be settable. > > > > > > > So given that 'unique per boot' is sufficient, what would be the > > > > > problem with simply adding a simple ever-increasing unique atomix > > > > > count to the struct user_namespace? > > > > > > > > I don't think there is any ... but I equally don't see why people > > > > would want to save and restore the uuid but not the new monotonic > > > > identifier ... because it's still just a marker on a namespace. > > > > > > But you've called it "the namespace uuid". I'm not even really > > > thinking of checkpoint/restart, just stopping and restarting a > > > container. I'm convinced people will want to start using it because, > > > well, it is a nice feature. > > > > Right, but the uniqueness property depends on you not being able to set > > it. If you just want a namespace label, you can have that, but > > anything a user can set is either a pain to guarantee uniqueness (have > > to check all the other objects) or is simply a non-unique label. > > > > If you want to label a container, which could have many namespaces and > > be stopped and restarted many times, it does sound like you want a non- > > unique settable label. However, IMA definitely needs a guaranteed per > > namespace unique label. > > > > Is the objection simply you think a UUID sound like it should be > > Objection is too strong. Concern. > > But yes, to me a uuid (a) feels like it should be generally useful > including being settable and (b) not super duper 100% absolutely > guaranteed to always be unique per boot, as an incremented counter > would be. I don't have strong feelings about uuid or counter. In something like an IMA log a uuid might be better but idk. I don't know enough about IMA to judge that. I see the problem you're getting at though. Making this a member of struct user_namespace will give the impression that is a generic identifier. I'd rather make it clear that this is an IMA-only thing. Ideally by not having it be a member of struct user_namespace at all or at least by naming it ima_uuid or similar. Christian
On Mon, 2021-11-29 at 14:12 +0100, Christian Brauner wrote: > On Sun, Nov 28, 2021 at 03:49:06PM -0600, Serge Hallyn wrote: > > On Sun, Nov 28, 2021 at 04:21:29PM -0500, James Bottomley wrote: > > > On Sun, 2021-11-28 at 14:47 -0600, Serge E. Hallyn wrote: > > > > On Sun, Nov 28, 2021 at 01:00:28PM -0500, James Bottomley > > > > wrote: > > > > > On Sun, 2021-11-28 at 09:18 -0600, Serge E. Hallyn wrote: [...] > > > > > > So given that 'unique per boot' is sufficient, what would > > > > > > be the problem with simply adding a simple ever-increasing > > > > > > unique atomix count to the struct user_namespace? > > > > > > > > > > I don't think there is any ... but I equally don't see why > > > > > people would want to save and restore the uuid but not the > > > > > new monotonic identifier ... because it's still just a marker > > > > > on a namespace. > > > > > > > > But you've called it "the namespace uuid". I'm not even really > > > > thinking of checkpoint/restart, just stopping and restarting a > > > > container. I'm convinced people will want to start using it > > > > because, well, it is a nice feature. > > > > > > Right, but the uniqueness property depends on you not being able > > > to set it. If you just want a namespace label, you can have > > > that, but anything a user can set is either a pain to guarantee > > > uniqueness (have to check all the other objects) or is simply a > > > non-unique label. > > > > > > If you want to label a container, which could have many > > > namespaces and be stopped and restarted many times, it does sound > > > like you want a non-unique settable label. However, IMA > > > definitely needs a guaranteed per namespace unique label. > > > > > > Is the objection simply you think a UUID sound like it should be > > > > Objection is too strong. Concern. > > > > But yes, to me a uuid (a) feels like it should be generally useful > > including being settable and (b) not super duper 100% absolutely > > guaranteed to always be unique per boot, as an incremented counter > > would be. > > I don't have strong feelings about uuid or counter. In something like > an IMA log a uuid might be better but idk. I don't know enough about > IMA to judge that. I see the problem you're getting at though. Making > this a member of struct user_namespace will give the impression that > is a generic identifier. I'd rather make it clear that this is an > IMA-only thing. I don't think that's possible; let's unwind and look at the requirements: We need a per log (i.e. per boot) unique label, that the user of the system can't tamper with, for the namespace to record in the IMA log. The chances are orchestration systems are likely going to want a way to query the label so they can tie their own internal name for a container that is using namespaced IMA to the entry in the log. Given these two requirements, it can't be an IMA only thing, it has to be some sort of marker on the namespace itself. > Ideally by not having it be a member of struct user_namespace at all > or at least by naming it ima_uuid or similar. I can call it ima_uuid, but Serge is right, given people are going to want to get it, we're not going to be able to prevent it being used for non-ima things. The main thing I was trying to make clear is the unique per boot and tamper proof property means there can't be an API to set it. Given the assumption people will use it for other things, it is necessary to think about the wider issues before settling on a scheme. From the security perspective I like UUIDs because they would make each IMA log unique which is a useful property to prevent replay or log faking, but I think a unique per boot counter would also work. James
On 11/28/21 20:59, Serge E. Hallyn wrote: > On Sun, Nov 28, 2021 at 05:56:28PM -0500, James Bottomley wrote: >> On Sun, 2021-11-28 at 15:49 -0600, Serge E. Hallyn wrote: >>> On Sun, Nov 28, 2021 at 04:21:29PM -0500, James Bottomley wrote: >>>> On Sun, 2021-11-28 at 14:47 -0600, Serge E. Hallyn wrote: >>>>> On Sun, Nov 28, 2021 at 01:00:28PM -0500, James Bottomley wrote: >>>>>> On Sun, 2021-11-28 at 09:18 -0600, Serge E. Hallyn wrote: >> [...] >>>>>>> So given that 'unique per boot' is sufficient, what would be >>>>>>> the problem with simply adding a simple ever-increasing >>>>>>> unique atomix count to the struct user_namespace? >>>>>> I don't think there is any ... but I equally don't see why >>>>>> people would want to save and restore the uuid but not the new >>>>>> monotonic identifier ... because it's still just a marker on a >>>>>> namespace. >>>>> But you've called it "the namespace uuid". I'm not even really >>>>> thinking of checkpoint/restart, just stopping and restarting a >>>>> container. I'm convinced people will want to start using it >>>>> because, well, it is a nice feature. >>>> Right, but the uniqueness property depends on you not being able to >>>> set it. If you just want a namespace label, you can have that, but >>>> anything a user can set is either a pain to guarantee uniqueness >>>> (have to check all the other objects) or is simply a non-unique >>>> label. >>>> >>>> If you want to label a container, which could have many namespaces >>>> and be stopped and restarted many times, it does sound like you >>>> want a non-unique settable label. However, IMA definitely needs a >>>> guaranteed per namespace unique label. >>>> >>>> Is the objection simply you think a UUID sound like it should be >>> Objection is too strong. Concern. >>> >>> But yes, to me a uuid (a) feels like it should be generally useful >>> including being settable and (b) not super duper 100% absolutely >>> guaranteed to always be unique per boot, as an incremented counter >>> would be. >> OK, but a bunch of cats I found on the Internet agree with me, a UUID >> shouldn't be settable: >> >> https://en.wikipedia.org/wiki/Universally_unique_identifier >> >> The key point being, if you can set the id, it can't be unique ... it > Ok, so can you just put a comment above there saying "this must not > be settable from userspace" ? So I have been working on an IMA namespacing series again as well and would like to use some sort of unique identifier for audit messages emitted from an IMA/user namespace other than the init_ima_ns. This UUID may just work for this, but how would one associate the UUID with a container if it ever comes to that when evaluating audit logs? Shouldn't it be settable from user space for some sort of 'coordination' between container runtime and kernel? Stefan
On Mon, Nov 29, 2021 at 08:49:40AM -0500, Stefan Berger wrote: > > On 11/28/21 20:59, Serge E. Hallyn wrote: > > On Sun, Nov 28, 2021 at 05:56:28PM -0500, James Bottomley wrote: > > > On Sun, 2021-11-28 at 15:49 -0600, Serge E. Hallyn wrote: > > > > On Sun, Nov 28, 2021 at 04:21:29PM -0500, James Bottomley wrote: > > > > > On Sun, 2021-11-28 at 14:47 -0600, Serge E. Hallyn wrote: > > > > > > On Sun, Nov 28, 2021 at 01:00:28PM -0500, James Bottomley wrote: > > > > > > > On Sun, 2021-11-28 at 09:18 -0600, Serge E. Hallyn wrote: > > > [...] > > > > > > > > So given that 'unique per boot' is sufficient, what would be > > > > > > > > the problem with simply adding a simple ever-increasing > > > > > > > > unique atomix count to the struct user_namespace? > > > > > > > I don't think there is any ... but I equally don't see why > > > > > > > people would want to save and restore the uuid but not the new > > > > > > > monotonic identifier ... because it's still just a marker on a > > > > > > > namespace. > > > > > > But you've called it "the namespace uuid". I'm not even really > > > > > > thinking of checkpoint/restart, just stopping and restarting a > > > > > > container. I'm convinced people will want to start using it > > > > > > because, well, it is a nice feature. > > > > > Right, but the uniqueness property depends on you not being able to > > > > > set it. If you just want a namespace label, you can have that, but > > > > > anything a user can set is either a pain to guarantee uniqueness > > > > > (have to check all the other objects) or is simply a non-unique > > > > > label. > > > > > > > > > > If you want to label a container, which could have many namespaces > > > > > and be stopped and restarted many times, it does sound like you > > > > > want a non-unique settable label. However, IMA definitely needs a > > > > > guaranteed per namespace unique label. > > > > > > > > > > Is the objection simply you think a UUID sound like it should be > > > > Objection is too strong. Concern. > > > > > > > > But yes, to me a uuid (a) feels like it should be generally useful > > > > including being settable and (b) not super duper 100% absolutely > > > > guaranteed to always be unique per boot, as an incremented counter > > > > would be. > > > OK, but a bunch of cats I found on the Internet agree with me, a UUID > > > shouldn't be settable: > > > > > > https://en.wikipedia.org/wiki/Universally_unique_identifier > > > > > > The key point being, if you can set the id, it can't be unique ... it > > Ok, so can you just put a comment above there saying "this must not > > be settable from userspace" ? > > So I have been working on an IMA namespacing series again as well and would > like to use some sort of unique identifier for audit messages emitted from > an IMA/user namespace other than the init_ima_ns. This UUID may just work > for this, but how would one associate the UUID with a container if it ever > comes to that when evaluating audit logs? Shouldn't it be settable from user > space for some sort of 'coordination' between container runtime and kernel? Wouldn't this be solved by the audit container id patchset? In fact, can't we use this for IMA as well?
On 11/29/21 08:56, Christian Brauner wrote: > On Mon, Nov 29, 2021 at 08:49:40AM -0500, Stefan Berger wrote: >> On 11/28/21 20:59, Serge E. Hallyn wrote: >>> On Sun, Nov 28, 2021 at 05:56:28PM -0500, James Bottomley wrote: >>>> On Sun, 2021-11-28 at 15:49 -0600, Serge E. Hallyn wrote: >>>>> On Sun, Nov 28, 2021 at 04:21:29PM -0500, James Bottomley wrote: >>>>>> On Sun, 2021-11-28 at 14:47 -0600, Serge E. Hallyn wrote: >>>>>>> On Sun, Nov 28, 2021 at 01:00:28PM -0500, James Bottomley wrote: >>>>>>>> On Sun, 2021-11-28 at 09:18 -0600, Serge E. Hallyn wrote: >>>> [...] >>>>>>>>> So given that 'unique per boot' is sufficient, what would be >>>>>>>>> the problem with simply adding a simple ever-increasing >>>>>>>>> unique atomix count to the struct user_namespace? >>>>>>>> I don't think there is any ... but I equally don't see why >>>>>>>> people would want to save and restore the uuid but not the new >>>>>>>> monotonic identifier ... because it's still just a marker on a >>>>>>>> namespace. >>>>>>> But you've called it "the namespace uuid". I'm not even really >>>>>>> thinking of checkpoint/restart, just stopping and restarting a >>>>>>> container. I'm convinced people will want to start using it >>>>>>> because, well, it is a nice feature. >>>>>> Right, but the uniqueness property depends on you not being able to >>>>>> set it. If you just want a namespace label, you can have that, but >>>>>> anything a user can set is either a pain to guarantee uniqueness >>>>>> (have to check all the other objects) or is simply a non-unique >>>>>> label. >>>>>> >>>>>> If you want to label a container, which could have many namespaces >>>>>> and be stopped and restarted many times, it does sound like you >>>>>> want a non-unique settable label. However, IMA definitely needs a >>>>>> guaranteed per namespace unique label. >>>>>> >>>>>> Is the objection simply you think a UUID sound like it should be >>>>> Objection is too strong. Concern. >>>>> >>>>> But yes, to me a uuid (a) feels like it should be generally useful >>>>> including being settable and (b) not super duper 100% absolutely >>>>> guaranteed to always be unique per boot, as an incremented counter >>>>> would be. >>>> OK, but a bunch of cats I found on the Internet agree with me, a UUID >>>> shouldn't be settable: >>>> >>>> https://en.wikipedia.org/wiki/Universally_unique_identifier >>>> >>>> The key point being, if you can set the id, it can't be unique ... it >>> Ok, so can you just put a comment above there saying "this must not >>> be settable from userspace" ? >> So I have been working on an IMA namespacing series again as well and would >> like to use some sort of unique identifier for audit messages emitted from >> an IMA/user namespace other than the init_ima_ns. This UUID may just work >> for this, but how would one associate the UUID with a container if it ever >> comes to that when evaluating audit logs? Shouldn't it be settable from user >> space for some sort of 'coordination' between container runtime and kernel? > Wouldn't this be solved by the audit container id patchset? In fact, > can't we use this for IMA as well? I suppose it's this yet-to-be-merged series you are referring to: https://lkml.org/lkml/2021/1/12/818 It would work for as long as it's *required* to set the identifier or the identifier is readily available when the first audit message needs to be emitted. If this is not the case then that unique identifier should maybe originate in the kernel and be queryable by user space but then again the same container may come up with different identifiers every time. I am not sure whether that is desirable. Some sort of 'base UUID' could be passed with the clone3() call and either all namespaces could derive from the base UUID or just get the same value. If that's not set the kernel gets to choose the base UUID... At least by updating container runtimes the coordination issue could be solved and with the clone3() call the early availability of the UUID could be guranteed?
On Mon, 2021-11-29 at 14:56 +0100, Christian Brauner wrote: > On Mon, Nov 29, 2021 at 08:49:40AM -0500, Stefan Berger wrote: > > On 11/28/21 20:59, Serge E. Hallyn wrote: > > > On Sun, Nov 28, 2021 at 05:56:28PM -0500, James Bottomley wrote: > > > > On Sun, 2021-11-28 at 15:49 -0600, Serge E. Hallyn wrote: > > > > > On Sun, Nov 28, 2021 at 04:21:29PM -0500, James Bottomley > > > > > wrote: > > > > > > On Sun, 2021-11-28 at 14:47 -0600, Serge E. Hallyn wrote: > > > > > > > On Sun, Nov 28, 2021 at 01:00:28PM -0500, James Bottomley > > > > > > > wrote: > > > > > > > > On Sun, 2021-11-28 at 09:18 -0600, Serge E. Hallyn > > > > > > > > wrote: > > > > [...] > > > > > > > > > So given that 'unique per boot' is sufficient, what > > > > > > > > > would be the problem with simply adding a simple > > > > > > > > > ever-increasing unique atomix count to the struct > > > > > > > > > user_namespace? > > > > > > > > I don't think there is any ... but I equally don't see > > > > > > > > why people would want to save and restore the uuid but > > > > > > > > not the new monotonic identifier ... because it's still > > > > > > > > just a marker on a namespace. > > > > > > > But you've called it "the namespace uuid". I'm not even > > > > > > > really thinking of checkpoint/restart, just stopping and > > > > > > > restarting a container. I'm convinced people will want > > > > > > > to start using it because, well, it is a nice feature. > > > > > > Right, but the uniqueness property depends on you not being > > > > > > able to set it. If you just want a namespace label, you > > > > > > can have that, but anything a user can set is either a pain > > > > > > to guarantee uniqueness (have to check all the other > > > > > > objects) or is simply a non-unique label. > > > > > > > > > > > > If you want to label a container, which could have many > > > > > > namespaces and be stopped and restarted many times, it does > > > > > > sound like you want a non-unique settable label. However, > > > > > > IMA definitely needs a guaranteed per namespace unique > > > > > > label. > > > > > > > > > > > > Is the objection simply you think a UUID sound like it > > > > > > should be > > > > > Objection is too strong. Concern. > > > > > > > > > > But yes, to me a uuid (a) feels like it should be generally > > > > > useful including being settable and (b) not super duper 100% > > > > > absolutely guaranteed to always be unique per boot, as an > > > > > incremented counter would be. > > > > OK, but a bunch of cats I found on the Internet agree with me, > > > > a UUID shouldn't be settable: > > > > > > > > https://en.wikipedia.org/wiki/Universally_unique_identifier > > > > > > > > The key point being, if you can set the id, it can't be unique > > > > ... it > > > Ok, so can you just put a comment above there saying "this must > > > not be settable from userspace" ? > > > > So I have been working on an IMA namespacing series again as well > > and would like to use some sort of unique identifier for audit > > messages emitted from an IMA/user namespace other than the > > init_ima_ns. This UUID may just work for this, but how would one > > associate the UUID with a container if it ever comes to that when > > evaluating audit logs? Shouldn't it be settable from user > > space for some sort of 'coordination' between container runtime and > > kernel? > > Wouldn't this be solved by the audit container id patchset? In fact, > can't we use this for IMA as well? Stefan asked, but it really doesn't have the properties we need, plus they don't seem to want the audit id used as the container id. How about this: Since the label has to be unique for the lifetime of the system, if we allow it to be settable, we'll have to carry it outside the namespace anyway because memory of the label has to live on after the namespace dies to avoid duplication, so I'll move it into a parallel namespace structure ima will carry. it will be settable once, but if you don't set it before it's used, then we'll set it to a randombly generated uuid. If you do set it, it will be checked for uniqueness against all previous labels. James
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h index 33a4240e6a6f..d155788abdc1 100644 --- a/include/linux/user_namespace.h +++ b/include/linux/user_namespace.h @@ -10,6 +10,7 @@ #include <linux/rwsem.h> #include <linux/sysctl.h> #include <linux/err.h> +#include <linux/uuid.h> #define UID_GID_MAP_MAX_BASE_EXTENTS 5 #define UID_GID_MAP_MAX_EXTENTS 340 @@ -99,6 +100,7 @@ struct user_namespace { #endif struct ucounts *ucounts; long ucount_max[UCOUNT_COUNTS]; + uuid_t uuid; } __randomize_layout; struct ucounts { diff --git a/kernel/user.c b/kernel/user.c index e2cf8c22b539..bf9ae1d0b670 100644 --- a/kernel/user.c +++ b/kernel/user.c @@ -67,6 +67,7 @@ struct user_namespace init_user_ns = { .keyring_name_list = LIST_HEAD_INIT(init_user_ns.keyring_name_list), .keyring_sem = __RWSEM_INITIALIZER(init_user_ns.keyring_sem), #endif + /* .uuid is initialized in user_namespaces_init() */ }; EXPORT_SYMBOL_GPL(init_user_ns); diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c index 6b2e3ca7ee99..8ce57c16ddd3 100644 --- a/kernel/user_namespace.c +++ b/kernel/user_namespace.c @@ -141,6 +141,8 @@ int create_user_ns(struct cred *new) if (!setup_userns_sysctls(ns)) goto fail_keyring; + uuid_gen(&ns->uuid); + set_cred_user_ns(new, ns); return 0; fail_keyring: @@ -1386,6 +1388,7 @@ const struct proc_ns_operations userns_operations = { static __init int user_namespaces_init(void) { user_ns_cachep = KMEM_CACHE(user_namespace, SLAB_PANIC | SLAB_ACCOUNT); + uuid_gen(&init_user_ns.uuid); return 0; } subsys_initcall(user_namespaces_init);
As a precursor to namespacing IMA a way of uniquely identifying the namespace to appear in the IMA log is needed. This log may be transported away from the running system and may be analyzed even after the system has been rebooted. Thus we need a way of identifying namespaces in the log which is unique. UUID, being designed probabilistically never to repeat, fits this bill so add it to the user_namespace which we'll also use for namespacing IMA. uuid_gen() is used to create each uuid uniquely. It feeds off the pseudo random number generator, but this should be as unique as we need for probabilistic non repeats without depleting the entropy pool. Since there is no random initializer for a uuid, this is done in user_namespaces_init(). This should be safe because IMA is a late initcall. This patch contains no exposure mechanisms, and the subsequent patches only add uuid entries in the IMA log. However, it is not unlikely that eventually orchestration systems will want to know what the uuid is (to tie their container ID to the one in the IMA log), so additional patches exposing this via NSIO and /proc/<pid>/ns could be added. For checkpoint/restore, the uuid should not be a property that transports because otherwise we'll have to have a set mechanism with a uniqueness check. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> --- include/linux/user_namespace.h | 2 ++ kernel/user.c | 1 + kernel/user_namespace.c | 3 +++ 3 files changed, 6 insertions(+)