On Thursday, December 5, 2019 5:32:55 AM MST Lennart Poettering wrote: > > Where is the advantage of homed, considering, that only encrypting > > /home, is a major security flaw by itself. All your goals are > > already there and it's more useful and secure too :) I really have a > > problem understanding why you wanne implement a security flaw and > > call it "better". > > > Locking down the OS itself and locking down the user's home are two > different things, because OS integrity should be bound to different > mechanisms than user data encryption. (i.e. OS integrity should be > bound to vendor trust or TPM, while user data should be bound to > user's security credentials). I could not disagree more. That would be fine if the trust were the user or the organization that owns the machine, but not vendor trust or anything of the like. It's not some third party's system, it's the user or organization's. Additionally, it's much easier to get a third party to sign something for you than to get the users themselves, or an organization, to sign it. > > If you wanne improve security, please focus on userfriendlyneess for > > things like "disabling unused usb ports"/"whitelist for usb > > ids"/"insecure Highspeed USB network adapter detection" same for any > > plugable port you have in your hw. And last, but not least, "motherboard > > serial number validation on wakeup" to counter the switch of hw > > components. > > Uh, locking down USB like that doesn't really work. USB has no > mechanism for recognizing devices securely, which means any whitelist > is pointless because any device can claim to be whatever it wants to > be. (And yes, it would be great if we could be a bit more secure > there, but it's an orthogonal problem) Well, that's not entirely true. For example, while devices could easily give a false VID and PID, even just limiting that would be a useful feature, because it'd limit the USB functionality of the system (only the modules Linux maps those VID/PID combos to would be available). -- John M. Harris, Jr. Splentity _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
