On Tue, Sep 6, 2022 at 8:10 PM John Johansen <john.johansen@xxxxxxxxxxxxx> wrote: > On 9/6/22 16:24, Paul Moore wrote: > > On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > >> On 9/2/2022 2:30 PM, Paul Moore wrote: > >>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > >>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: ... > > If you are running AppArmor on the host system and SELinux in a > > container you are likely going to have some *very* bizarre behavior as > > the SELinux policy you load in the container will apply to the entire > > system, including processes which started *before* the SELinux policy > > was loaded. While I understand the point you are trying to make, I > > don't believe the example you chose is going to work without a lot of > > other changes. > > correct but the reverse does work ... Sure, that doesn't surprise me, but that isn't the example Casey brought up. > >>> I think it's time to think about a proper set of LSM syscalls. > >> > >> At the very least we need a liblsm that preforms a number of useful > >> functions, like identifying what security modules are available, > >> validating "contexts", fetching "contexts" from files and processes > >> and that sort of thing. Whether it is built on syscalls or /proc and > >> getxattr() is a matter of debate and taste. > > > > Why is it a forgone conclusion that a library would be necessary for > > basic operations? If the kernel/userspace API is sane to begin with > > we could probably either significantly reduce or eliminate the need > > for additional libraries. I really want us to attempt to come up with > > a decent kernel/userspace API to begin with as opposed to using the > > excuse of a userspace library to hide API sins that never should have > > been committed. > > I don't think its a foregone conclusion, its just that it has been > discussed several times, and all the interfaces have been nasty and > prebaked userspace code would be really nice to have. > > There are other reasons to use a lib as well. Libs can help apps > pickup fixes/changes automatically. Fair point. > > The LSM stacking work presents us with a unique opportunity to > > modify/update/whatever the LSM kernel/userspace API, I don't want to > > see us squander this chance on a hack. > > I do wish we had a better API from the beginning. I just hope it isn't > going to take another 10 years to get the API portion done. This really should surprise no one at this point, but I care very little about how long something might take, or how difficult it might be if it is something we are going to have to live with <dramatic_voice>forever</dramatic_voice>. I'm sympathetic that this work has been going on for some time, but that is no reason to push through a bad design; look at the ACKs/reviews on the combined-label patches vs the others in the series, that's a pretty good indication that no one is really excited about that design. > >> The /proc interfaces interface_lsm and context are really pretty simple. > > > They are now, they are also a bit of a mess with legacy constraints > > and they only get more complicated and messy with the LSM stacking > > patches. It is my opinion that a syscall-based API is cleaner and > > easier for applications to use. > > potentially if we can get one Let me try and remove some ambiguity from that - I'm not going to merge any combined-label APIs. I'm not sold on the syscall-based API, I'm open to other ideas, but it needs to support distinct per-LSM labels that allow applications to identify which LSMs are active and which labels belong to each. In addition, I do not want any changes to the existing procfs APIs as I want there to be zero chance we will break existing applications; if existing applications need to be made aware of a simul-multi-LSM world then they would need to change to the new API, whatever that may be. > >>> Further, I think we can add the new syscall API separately from the > >>> LSM stacking changes as they do have standalone value. > > what I think Paul is saying is we can move the LSM stacking patches > forward by removing the combined label interface. They won't be as > useful but it would be a huge step forward, and the next step could > be the syscall API. Whatever new LSM API we decide on, I want to see that developed and merged first. It obviously must be designed to support multiple, simultaneously active LSMs. -- paul-moore.com
