Page 6 of 6 FirstFirst ... 456
Results 51 to 55 of 55

Thread: Starch Linux: OpenBSD Atop Arch's Linux Kernel

  1. #51

    Default

    Quote Originally Posted by ncopa View Post
    I never claimed that bsd jails are more secure, because I don't know those.
    As far as I know, there is no known way to break out of a BSD jail in the default configuration on FreeBSD. If you modify a FreeBSD jail to add certain devices in /dev from the host to the jail, enable UNIX System V shared memory or a few other things, then it becomes possible to break out.

  2. #52

    Default

    Quote Originally Posted by ryao View Post
    As far as I know, there is no known way to break out of a BSD jail in the default configuration on FreeBSD. If you modify a FreeBSD jail to add certain devices in /dev from the host to the jail, enable UNIX System V shared memory or a few other things, then it becomes possible to break out.
    That is what I expected. Even the wikipedia article says that one of the three goals for a jail is security while Linux developers claimes that chroot is not and never has been a security tool.

    I got a bit surprised to see someone claim that even Linux chroots are more secure than BSD jails. I guess someone on the internet is wrong...

  3. #53

    Default

    Quote Originally Posted by ncopa View Post
    That is what I expected. Even the wikipedia article says that one of the three goals for a jail is security while Linux developers claimes that chroot is not and never has been a security tool.

    I got a bit surprised to see someone claim that even Linux chroots are more secure than BSD jails. I guess someone on the internet is wrong...
    Both jails and chroots are available on FreeBSD. They are not mutually exclusive. chroot is not and never has been a security tool on FreeBSD either.

  4. #54
    Join Date
    Jan 2013
    Posts
    1,116

    Default

    Quote Originally Posted by systemd anals bsd View Post
    Linux chroots are far more secure then BSD jails or chroots. BSD jails make the crappy OS even more vulnerable.
    Any facts on this? Or just your "informed opinion"?

  5. #55
    Join Date
    Jan 2010
    Location
    Ghent
    Posts
    221

    Default

    Quote Originally Posted by ncopa View Post
    Static linking is generally a bad idea. You'll end up with multiple copies of same code in memory -> bloat. You'll probably end up using more memory than with glibc.

    Check out Alpine Linux. Uses uclibc and busybox and shared libs.

    There are strong and weak points with both static and dynamic linking. I do not even presume to know all the details, but a static binary does not have to be executed via the linker, so it is generally started faster (you might loose RAM but you win CPU...). Other strong points with static binaries is that they are portable (you do not have to package a bundle of dlls together with your binary) and will stay executeable on a specific architecture/kernel combination for a _very_ long time. An all-static OS like Plan9 is far from being bloated.

    Another huge advantage is that the whole system does not break down if libc breaks.

    For a standard desktop, static linking would probably be a bad thing. On the other hand, for small and true "unixy" applications, static linking against light-weight libraries makes a lot of sense.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •