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