How to Make OS X Partition Smaller?
You should be able to resize the CoreStorage stack by booting to a second boot volume (e.g. Internet Recovery Mode) after modifying the partition table. Afterwards you have to re-add the partitions in the old boundaries but with proper types.

Preparation:


Restart to Internet Recovery Mode by pressing alt cmd R at startup. 

The prerequisites are the latest firmware update installed, either ethernet or WLAN (WPA/WPA2) and a router with DHCP activated.
On a 50 Mbps-line it takes about 4 min (presenting a small animated globe) to boot into a recovery netboot image which usually is loaded from an Apple/Akamai server.

I recommend ethernet because it's more reliable. If you are restricted to WIFI and the boot process fails, just restart your Mac until you succeed booting.

Alternatively you may start from a bootable installer thumb drive (preferably Yosemite or El Capitan) or a thumb drive containing a full system (preferably Yosemite or El Capitan). If you boot to a full system and login as admin you have to prepend sudo to execute some commands like gpt ... or newfs_hfs ...!


Remove the bogus MBR/GPT and re-add the partitions


Open in the menubar Utlities->Terminal
Enter diskutil list and gpt -r show /dev/disk0 to get an overview
Destroy the bogus GUID partition table/MBR and recreate a fresh one:

diskutil umountDisk /dev/diskX #with diskX = disk identifier of the logical volume
diskutil umountDisk /dev/disk0
gpt destroy /dev/disk0
diskutil umountDisk /dev/disk0
gpt create -f /dev/disk0

Re-add the partitions:

gpt add -b 40 -i 1 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk0
gpt add -b 488966144 -i 3 -s 1267712 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk0
gpt add -b 150150032 -i 4 -s 86566407 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 /dev/disk0
gpt add -b 148880496 -i 2 -s 148470856 -t 53746F72-6167-11AA-AA11-00306543ECAC /dev/disk0

The logical volume should mount automatically if not encrypted. If not you may have to unlock it.
Verify the disk and the volume and try to repair them if necessary
Unlock your FileVault volume

diskutil cs unlockVolume lvUUID

Resize the CoreStorage stack

diskutil cs resizestack lvUUID size


e.g.

diskutil cs resizestack 20C85797-328F-4A27-B0DE-97DB2B14F1D7 65000m

if this fails you may have to decrypt the FileVault volume

diskutil cs unlockVolume 20C85797-328F-4A27-B0DE-97DB2B14F1D7
diskutil cs decryptVolume 20C85797-328F-4A27-B0DE-97DB2B14F1D7


and get the new device node with

diskutil list

Verify the decrypted volume (e.g. disk16)

diskutil verifyVolume /dev/disk16

Try to resize the CoreStorage stack again (like above)

diskutil cs resizestack lvUUID size





Resizing you Linux partition from inside Linux afterwards will probably hose your current MBR (and/or GPT) and will render one or both systems unbootable.



Tested in a VM:

Resizing the unlocked but encrypted volume from a second boot volume failed with an error number and some "booter is mounted" message. The reason for the message may be the following: the FileVault volume (disk0s2/disk16) relies on some files in the Recovery HD (disk0s3). Resizing the stack means shrinking the Logical Volume Group and all subsequent CoreStorage items and moving the Recovery HD to lower block numbers afterwards. The Recovery HD has to be unmounted to achieve this.

Using real partitions may yield different results or errors.