• 1 Post
  • 56 Comments
Joined 4 years ago
cake
Cake day: January 21st, 2021

help-circle



  • The concern is that it would be nice if the UNIX users and LDAP is automatically in sync and managed from a version controlled source. I guess the answer is just build up a static LDAP database from my existing configs. It would be nice to have one authoritative system on the server but I guess as long as they are both built from one source of truth it shouldn’t be an issue.


  • Yes, LDAP is a general tool. But many applications that I am interested in using it for user information. That is what I want to use it for. I’m not really interested in storing other data.

    I think you are sort of missing the goal of the question. I have a bunch of self-hosted services like Jellyfin, qBittorrent, PhotoPrism, Metabase … I want to avoid having to configure users in each one individually. I am considering LDAP because it is supported by many of these services. I’m not concerned about synchronizing UNIX users, I already have that solved. (If I need to move those to LDAP as well that can be considered, but isn’t a goal).


  • I do use a reverse proxy but for various reasons you can’t just block off some apps. For example if you want to play Jellyfin on a Chromecast or similar, or PhotoPrism if you want to use sharing links. Unfortunately these systems are designed around the built-in auth and you can’t just slap a proxy in front.

    I do use nginx with basic with in front of services where I can. I trust nginx much more than 10 different services with varying quality levels. But unfortunately not all services play well.


  • How are you configuring this? I checked for Jellyfin and their are third-party plugins which don’t look too mature, but none of them seem to work with apps. qBittorrent doesn’t support much (actually I may be able to put reverse-proxy auth in front… I’ll look into that) and Metabase locks SSO behind a premium subscription.

    IDK why but it does seem that LDAP is much more widely supported. Or am I missing some method to make it work







  • This is my dream. However I think my target market is smaller and less willing to pay (personal rather than business). However maintenance is low effort and I want the product for myself. So even if it doesn’t make much or anything I think I will be happy to run it forever.

    The ultimate dream would be to make enough to be able to employ someone else part time, so that there could be business continuity if I wasn’t able to run it anymore.


  • kevincox@lemmy.mltoSelfhosted@lemmy.worldSecurity and docker
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 months ago

    There is definitely isolation. In theory (if containers worked perfectly as intended) a container can’t see any processes from the host, sees different filesystems, possibly a different network interface and basically everything else. There are some things that are shared like CPU, Memory and disk space but these can also be limited by the host.

    But yes, in practice the Linux kernel is wildly complex and these interfaces don’t work quite as well as intended. You get bugs in permission checks and even memory corruption and code execution vulnerabilities. This results in unintended ways for code to break out of containers.

    So in theory the isolation is quite strong, but in practice you shouldn’t rely on it for security critical isolation.


  • kevincox@lemmy.mltoSelfhosted@lemmy.worldSecurity and docker
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 months ago

    where you have decent trust in the software you’re running.

    I generally say that containers and traditional UNIX users are good enough isolation for “mostly trusted” software. Basically I know that they aren’t going to actively try to escalate their privilege but may contain bugs that would cause problems without any isolation.

    Of course it always depends on your risk. If you are handing sensitive user data and run lots of different services on the same host you may start to worry about remote code execution vulnerabilities and will be interested in stronger isolation so that a RCE in any one service doesn’t allow escalation to access all data being processed by other services on the host.



  • kevincox@lemmy.mltoSelfhosted@lemmy.worldSecurity and docker
    link
    fedilink
    English
    arrow-up
    2
    ·
    4 months ago

    The Linux kernel is less secure for running untrusted software than a VM because most hypervisors have a far smaller attack surface.

    how many serious organization destroying vulnerabilities have there been? It is pretty solid.

    The CVEs differ? The reasons that most organizations don’t get destroyed is that they don’t run untrusted software on the same kernels that process their sensitive information.

    whatever proprietary software thing you think is best

    This is a ridiculous attack. I never suggested anything about proprietary software. Linux’s KVM is pretty great.


  • kevincox@lemmy.mltoSelfhosted@lemmy.worldSecurity and docker
    link
    fedilink
    English
    arrow-up
    3
    ·
    4 months ago

    I think assuming that you are safe because you aren’t aware of any vulnerabilities is bad security practice.

    Minimizing your attack surface is critical. Defense in depth is just one way to minimize your attack surface (but a very effective one). Putting your container inside a VM is excellent defense in depth. Putting your container inside a non-root user barely is because you still have one Linux kernel sized hole in your swiss-cheese defence model.


  • kevincox@lemmy.mltoSelfhosted@lemmy.worldSecurity and docker
    link
    fedilink
    English
    arrow-up
    3
    ·
    4 months ago

    I never said it was trivial to escape, I just said it wasn’t a strong security boundary. Nothing is black and white. Docker isn’t going to stop a resourceful attacker but you may not need to worry about attackers who are going to spend >$100k on a 0-day vulnerability.

    The Linux kernel isn’t easy to exploit as if it was it wouldn’t be used so heavily in security sensitive environments

    If any “security sensitive” environment is relying on Linux kernel isolation I don’t think they are taking their sensitivity very seriously. The most security sensitive environments I am aware of doing this are shared hosting providers. Personally I wouldn’t rely on them to host anything particularly sensitive. But everyone’s risk tolerance is different.

    use podman with a dedicated user for sandboxing

    This is only every so slightly better. Users have existed in the kernel for a very long time so may be harder to find bugs in but at the end of the day the Linux kernel is just too complex to provide strong isolation.

    There isn’t any way to break out of a properly configured docker container right now but if there were it would mean that an attacker has root

    I would bet $1k that within 5 years we find out that this is false. Obviously all of the publicly known vulnerabilities have been patched. But more are found all of the time. For hobbyist use this is probably fine, but you should acknowledge the risk. There are almost certainly full kernel-privilege code execution vulnerabilities in the current Linux kernel, and it is very likely that at least one of these is privately known.


  • kevincox@lemmy.mltoSelfhosted@lemmy.worldSecurity and docker
    link
    fedilink
    English
    arrow-up
    7
    ·
    4 months ago

    It is. Privilege escalation vulnerabilities are common. There is basically a 100% chance of unpatched container escapes in the Linux kernel. Some of these are very likely privately known and available for sale. So even if you are fully patched a resourceful attacker will escape the container.

    That being said if you are a low-value regular-joe patching regularly, the risk is relatively low.


  • kevincox@lemmy.mltoSelfhosted@lemmy.worldSecurity and docker
    link
    fedilink
    English
    arrow-up
    12
    ·
    4 months ago

    Docker (and Linux containers in general) are not a strong security boundary.

    The reason is simply that the Linux kernel is far too large and complex of an interface to be vulnerability free. There are regular privilege escalation and container escapes found. There are also frequent Docker-specific container escape vulnerabilities.

    If you want strong security boundaries you should use a VM, or even better separate hardware. This is why cloud container services run containers from different clients in different VMs, containers are not good enough to isolate untrusted workloads.

    if Gossa were to be a virus, would I have been infected?

    I would assume yes. This would require the virus to know an unpatched exploit for Linux or Docker, but these frequently appear. There are likely many for sale right now. If you aren’t a high value target and your OS is fully patched then someone probably won’t burn an exploit on you, but it is entirely possible.