Announcement

Collapse
No announcement yet.

Skype 4.3 For Linux Released With Updated UI

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by DrYak View Post
    A different possibility would be AppArmor:

    Code:
    #include <tunables/global>
    
    /usr/bin/skype {
      #include <abstractions/audio>
      #include <abstractions/base>
      #include <abstractions/bash>
      #include <abstractions/kde>
      #include <abstractions/nameservice>
      #include <abstractions/ssl_certs>
      #include <abstractions/dbus-session>
    
      network dgram,
      network stream,
    
      /home/*/Documents/** r,
      /home/*/Documents/ r,
      /home/*/Pictures/** rw,
      /home/*/Pictures/ rw,
      /home/*/download/** rw,
      /home/*/download/ rw,
    
    
      deny /bin/bash r,
      deny /etc/group m,
      deny /etc/passwd m,
      deny owner /home/*/ r,
      deny /home/*/.kde4/share/config/ w,
      deny /home/*/.mozilla/ r,
      deny owner /home/*/Documents/ r,
      deny owner /home/*/* w,
      deny /proc/*/net/route r,
      deny /sys/devices/system/cpu/ r,
      deny /usr/bin/dbus-launch x,
      deny /usr/bin/kfmclient x,
      deny /usr/bin/xdg-open x,
      deny /usr/lib64/firefox/firefox.sh x,
    
      /usr/bin/pavucontrol Ux,
      /dev/ r,
      /dev/shm/ r,
      owner /dev/shm/pulse-shm-* mrw,
      /dev/snd/* mrw,
      /dev/video* mrw,
      /etc/X11/fs/config r,
      /etc/kde4/share/config/kdebugrc r,
      /etc/kde4rc r,
      /etc/ssl/openssl.cnf r,
      /etc/pulse/client.conf r,
      /etc/alsa-pulse.conf r,
      /etc/asound-pulse.conf r,
      owner /home/*/.ICEauthority r,
      owner /home/*/.Skype rw,
      owner /home/*/.Skype/ rw,
      owner /home/*/.Skype/** rwk,
      owner /home/*/.Xauthority r,
      owner /home/*/.asoundrc r,
      owner /home/*/.config/Polyester/Style.conf rk,
      owner /home/*/.config/Trolltech.conf rwk,
      owner /home/*/.fontconfig/ w,
      owner /home/*/.fontconfig/* mrw,
      owner /home/*/.fonts.conf r,
      owner /home/*/.fonts/** m,
      owner /home/*/.icons/** r,
      owner /home/*/.kde*/share/config/kdeglobals rk,
      owner /home/*/.kde/share/config/kioslaverc r,
      owner /home/*/.kde4/share/config/kdebugrc r,
      owner /home/*/.pulse-cookie rwk,
      owner /home/*/.pulse/ rw,
      owner /home/*/.qt/* rw,
      /opt/kde3/share/fonts/ r,
      /opt/kde3/share/fonts/** mr,
      owner /proc/*/fd/ r,
      /proc/interrupts r,
      /usr/bin/skype mr,
      /usr/lib/qt4/plugins/iconengines/ r,
      /usr/lib/qt4/plugins/imageformats/ r,
      /usr/lib/qt4/plugins/inputmethods/ r,
      /usr/lib64/jvm/java*/jre/lib/fonts/** mr,
      /usr/share/X11/XKeysymDB r,
      /usr/share/X11/locale/** r,
      /usr/share/desktop-data/qtrc r,
      /usr/share/fonts/ r,
      /usr/share/fonts/** mr,
      /usr/share/ghostscript/fonts/ r,
      /usr/share/ghostscript/fonts/** mr,
      /usr/share/icons/** mrk,
      /usr/share/kde4/config/kdebug.areas r,
      /usr/share/kde4/config/kdebugrc r,
      /usr/share/skype/lang/* mr,
      /usr/share/skype/sound/* r,
      /usr/share/skype/sounds/* rk,
      /usr/share/ssl/ r,
      /usr/share/texmf/fonts/** r,
      /var/lib/dbus/machine-id r,
      owner /var/tmp/kdecache-*/icon-cache.kcache mrw,
      owner /var/tmp/kdecache-*/kpc/kde-icon-cache.data mrw,
      owner /var/tmp/kdecache-*/kpc/kde-icon-cache.index mrw,
    }
    Notes:
    - NOT tested against today's Skype 4.3 (yet).
    - you should edit which sub-part of /home/ you need to allow acces to skype (Documents, etc.)
    - in order not to break pulseaudio, this profile enables dbus. But there's currently no fine-grained control of dbus in AppArmor. (you can't restrict Skype to only pulseaudio-related namespace).

    To all systemd-haters:
    - this is actually the kind of stuff that systemd is going to make much more simple:
    - start any "suspicious software" in its own LXC session (fast, without much configuring) and use portals and similar to communicate with the actual desktop.
    and people complain about systemd's much simpler proposed security... useful solution though.

    Comment


    • #32
      You can run Skype from within a docker container with X11 forwarding and PulseAudio over network routing.



      Or via systemd-nspawn container.

      Red Hat Enterprise Linux 7 RC was released some time ago. Since the beta was already quite decent I wanted to toy around with the RC version. My setup is quite unique. My root filesystem is on ZFS …
      Last edited by blackout23; 18 June 2014, 05:26 PM.

      Comment


      • #33
        Originally posted by birdie View Post
        Run it under a separate user
        Interesting solution, although I wonder if it's quite as secure as it's supposed to be. A separate user still has a lot of access to the system. Also, the commands are specific to Xorg. Oh, and from the looks of it, that chown is trying to do something with a directory that just got moved.

        Originally posted by DrYak View Post
        A different possibility would be AppArmor:

        Notes:
        - NOT tested against today's Skype 4.3 (yet).
        - you should edit which sub-part of /home/ you need to allow acces to skype (Documents, etc.)
        - in order not to break pulseaudio, this profile enables dbus. But there's currently no fine-grained control of dbus in AppArmor. (you can't restrict Skype to only pulseaudio-related namespace).

        To all systemd-haters:
        - this is actually the kind of stuff that systemd is going to make much more simple:
        - start any "suspicious software" in its own LXC session (fast, without much configuring) and use portals and similar to communicate with the actual desktop.
        That looks more nicely fine-grained. Though is AppArmor still being maintained and such?

        And yea, I'm thinking about a systemd solution. It has its own things like InaccessibleDirectories, PrivateTmp etc. which provide pretty good guarantees. Having a secure Skype unit file like that would be very convenient.

        Comment


        • #34
          Originally posted by blackout23 View Post
          You can run Skype from within a docker container with X11 forwarding and PulseAudio over network routing.



          Or via systemd-nspawn container.

          http://maci0.wordpress.com/2014/05/0...am-pidgin-vlc/
          That's interesting too, but this seems to be a bit overkill. Lennart suggests using properly configured unit files instead of nspawn for security purposes:

          Comment


          • #35
            Why in hell is everyone crying about ALSA being dropped??? this is a good thing, i can finally use my mic using skype on linux now...

            The real issues are with the UI (all grey looks like win95), no group video chat and no facebook chat integrated.
            they did some nice UI changes but its not nearly enough, settings are much nicer with updated icons and stuff but the rest is still this grey poop.

            Comment


            • #36
              Skype is dropping Alsa support?
              I guess I will stay with my old version for a while... I am a little affraid of Pulseaudio, since I had had issues with it.
              I am also afraid installing pulseaudio on my arch desktop would ruin every single app I configured to work with alsa (and there's a lot of them).
              I currently have my 5.1 USB headset perfectly working with alsa, so there's no hurry at all.

              I was wondering, though... Have the pulseaudio latency problems been resolved, or is it still uncomfortable for, let's say, gaming?

              EDIT : Four "I"? That's a bit of a monologue =D Sorry for that.
              Last edited by M@yeulC; 18 June 2014, 07:12 PM.

              Comment


              • #37
                Advice to Michael: If you post an article about an updated UI, post a screenshot as well, please. People may want to decide whether to install it based on a screenshot. Yes, they can search, but isn't the article supposed to be one of the search results?

                Comment


                • #38
                  Originally posted by M@yeulC View Post
                  I was wondering, though... Have the pulseaudio latency problems been resolved, or is it still uncomfortable for, let's say, gaming?
                  EDIT : Four "I"? That's a bit of a monologue =D Sorry for that.
                  I've been using Pulseaudio (on Arch Linux) for almost a year, and I game fairly frequently using wine + pulseaudio patch(Guildwars 2, Dragon Age Orgins/2, Mass Effect) and there's no noticeable latency, if any.

                  Comment


                  • #39
                    Originally posted by M@yeulC View Post
                    Skype is dropping Alsa support?
                    I guess I will stay with my old version for a while... I am a little affraid of Pulseaudio, since I had had issues with it.
                    I am also afraid installing pulseaudio on my arch desktop would ruin every single app I configured to work with alsa (and there's a lot of them).
                    I currently have my 5.1 USB headset perfectly working with alsa, so there's no hurry at all.

                    I was wondering, though... Have the pulseaudio latency problems been resolved, or is it still uncomfortable for, let's say, gaming?

                    EDIT : Four "I"? That's a bit of a monologue =D Sorry for that.
                    PulseAudio still has higher latency than pure ALSA or JACK, but I don't think there's any actual "problems". I use PA for gaming, and no issues. In fact, only Skype has ever given me issues, and maybe that'll finally be fixed now.

                    Comment


                    • #40
                      Originally posted by schmidtbag View Post
                      I think it's weird that they'd go out of their way to remove ALSA support. I think it'd be easier to just leave it in there.
                      Not at all weird. You seem to think that code just keeps working if you don't touch it, but that's nonsense - if they've changed anything else about how audio is managed, the ALSA code will likely need code changes. And any developer, given the choice between maintaining two code paths versus maintaining one, is going to take the opportunity to simplify the code base by deleting the bits that nobody really cares about anymore.

                      Comment

                      Working...
                      X