Chuck Norris wedi bod yn wneud hynny hefyd yn ddiolch. Rwyf ni'n gwych yn cael ei wneud am fwy teimlo i weld gweithiau ynchân Ymwêr. Rwyf wedi bod yn gweithio. Rwy'n gwych yn yr hyn maen nhw'n lleol yn cael ei fod gennych. Diolch yn ymddangos i'r dyfyrdd am y cyfaint. Rwyf wedi'i gweithio i'r union yn cael eu cyfaint yn cael eu phiwyr. Rwyf wedi bod yn cydweithio i fod i'r fwy. Felly, mae'n gweithio ar Ymwêr. We're going to look at some ways of attacking VMware networks and I'll also show you the tools that I've developed to help us do this. So afterwords hopefully you'll all be leaked VMware hackers able to own an entire network just by popping the one box. My name's John Fitzpatrick, I work as a pen tester for MWR info security in the UK. For the last six months or so I've spent all the spare hours battling against VMware's APIs. In the process I've found some pretty interesting stuff. It's my intention today to share this with you. We'll demonstrate some of the potential attack vectors. Hopefully you'll learn something interesting. The slides have changed slightly from what's on the DVD but not massively. The latest slides will be available to pull down from our website and I'll give you the URLs at the end. As was mentioned I'll be in the QA room afterwards if anyone's got any questions. So why VMware?  Virtualisation's taken off and it's rare that I'll go on a pen test now and not see some form of virtualisation. Normally it's VMware. In fact this research was all kicked off when I was on a pen test. I gained access to VMware server console but the desktop was locked and it meant if I wanted to get anywhere with that I'd have had to boot the guy off that was on the box. Which probably wasn't a good idea. In this case it wasn't such a problem. We could gain access to the box in other ways but I thought well if that comes up again in the future I want to be able to get on this box and I want to have a play. So I guess probably a lot of you have played about with VMware before. Some of you maybe have got virtualised networks back in your office or wherever you work. The structure of the presentation. We're going to start by looking at VMware, the different flavours and some of the key concepts. We'll move on to VMware server. We'll look at some ways of attacking that. I've got about six demos in total to show you so hopefully they'll all run fine. Some of these demos are for ESX and we'll look at ESX, some of the different attack vectors for that. We'll move on to a tool which was developed by a colleague of mine called Drardis. Which is a good tool for information sharing, sort of structuring your information whilst you're on a pen test. Then of course we'll shift on to some recommendations afterwards and see how you can help to take yourself if you're running VMware. We'll kick off with an introduction to VMware. There's loads of different flavours of VMware but here's a few listed here. You start off with the basic player which is there simply to play virtual machines. Workstations, perhaps a step up from that. You've got far more functionality there. You can create snapshots, that kind of thing. VMware server or kind of what used to be called GSX. ESX are the two main ones. They're the ones I'm interested in anyway because they're the ones that expose a service on the network. Purely because of that they provide something that we can attack. We're going to look at server and ESX today. The key concept with virtualisation, you have one server which can run multiple guest operating systems. Essentially one piece of hard work can be many many boxes on your network. In fact with VMware's virtual infrastructure this kind of comes out more in a many many relationship. Perhaps you'll run multiple ESX boxes again with multiple operating systems on it. VMware server looks something like this. You've got your hardware. On top of that you'll install your operating system. Whether this be Windows, Linux, whatever. The operating system is the light blue layer at the bottom. On top of that you'll install VMware server. On top of that you can create your virtual machines which all have their own operating system. Whatever applications you're running on them. ESX is slightly different. ESX essentially is the operating system. By running ESX you strip out one layer of the complexity there. Your virtual machines therefore can talk to ESX which can talk directly to the hardware. If you want to give two gig of RAM to a virtual machine it's got no operating system to contend with for that RAM. It can talk directly to ESX which will give it the RAM it wants. Now virtual machines because they're virtual they're made up of several different files. Here's a few of them. The VMX files, the main configuration file. This is what's actually executed by VMware and it contains things like the virtual machine name, settings, MAC address, hard drive settings, that kind of thing. VMDK is the disk file. It's essentially the virtual machine's hard drive and it stores all your data that's stored on your virtual machine. VMSN, because of the way virtual machines work you can create snapshots of them quite easily. If you want to go screwing about with something you just create a snapshot of your machine. If it ends up messing up your machine you can just revert back with no problems at all. That information is stored in the VMSN file. Then you've got the VMM file which is your virtual machine's memory. Now you're not going to see this unless your virtual machine is running or maybe it's crashed. You'll probably see it for some of your snapshots there. Now because virtual machines have a disk file we can look into reading data from that. The first demo I'll show you will read some data from a disk file and show how important it is that you ensure that this is secured and protected on your network. The tool we're going to use for this is a tool provided by VMware. It's called VMware Mount. Can you read the text on that on the back? Is that okay? Yep, yep, cool. Here first of all we're going to take a look at the position table on the virtual machine. It's a Windows XP machine. You can see that. Pretty much from the name of the disk file we're specifying. If we run that we can see that there's just one partition. It's NTFS which is kind of what we'd expect if it's a Windows machine. Next step is just to mount that. We do that again with the same command. We specify the partition we want to mount and where we want to mount it to. In this case we're mounting it to slash mount slash VMware. Just say yes to them. There you go, we've mounted the drive. If we just change to a new window there. There you go, we can see the contents of our Windows hard drive. From that we can have a quick play. In this case we'll jump into the system32 config file directory. Grab the syskey and then pull out the password hashes. From there it's nice and easy just to run a tool like John Ripper. We can use that just to crack all the passwords. Which is done quite nicely there. In this case we went for the password file. For the passwords for the box we could have gone for anything, any sensitive files. One thing that's worth noting is because you've got the ability to create snapshots. As soon as you build your virtual machine all of your files on that are there. Any changes you make are then made on top of that. If you say that you can revert to your original virtual machine your original files are still there. Anything you delete on your disk file it's still there even if it's not present on the virtual machine. We've had a look at some of the key concepts of VMware. Next we'll shift on and have a look at VMware server. VMware server looks something like this. In fact it looks exactly like that, that's a screenshot. VMware servers manage through the console which is what you can see there. On the left we've got the inventory which contains a list of all the virtual machines. On the right we've got the window there with the desktop on there. That's all VNC. If you're administering your VM from the console be aware that anyone else that's logged on to that server can also watch what you're doing. Which is probably part of the reason that VMware recommend that you don't manage your virtual machines from the console. Also I guess there's some performance issues there if you do. VMware server will authenticate against the local accounts in the box. Be careful if you've got a guest account enabled because someone could just jump on your box and browse through it. Whether you can run a virtual machine is kind of down to your file system permissions. So make sure you lock that down as well. Now if we want to attack VMware server the first thing we need to do is spot it on the network. Now this can be spotted on port 902. That's where VMware AuthD runs which is the authentication daemon. If you netcat onto that you can see in the banner that it's VMware. The rest of the ports I mean they could be anything. It depends where else is running on the box. Now communication with VMware server looks something like that. This is just us logging into the box. By default it does use SSL but if like me you don't quite have Brush and ISV and can't decrypt SSL in real time then it's quite useful just to flick that off and you can do that from the console. Now VMware provide several tools for managing their systems. For VMware server they provide a tool called VMware command which comes with VMware server. It's a nice tool, it's got some useful functionality. It's kind of a pain to use against a large number of systems or if you want to perform lots of tasks because you've got to pass the configuration file to it every time. To get around this problem what I've created is a Ruby module which essentially allows you to access this functionality. It works as basically a wrapper around VMware command.  Something else provided for VMware server is the VIX API. I don't know if any of you have used it. It's quite a powerful API. You can do stuff like transfer files back and forth from the host operating system to the guest operating systems. You can even run programs in the guest operating system if you like. Now it's got Perlin C bindings. In order to use it you've got a fair amount of code you need to write. But a lot of the operations that are there they're not available from the console directly which is probably the reason that a lot of people are spoken to you don't even realise that that functionality exists. One thing that's interesting to note is if you're copying files back and forth using the VIX API it doesn't use the network so there's no traffic for someone to detect. It talks directly with the virtual machine. Now I've written some Ruby bindings for this because when I'm testing I don't want to sit and write 130 lines of C code. So here you can see how easy it is to script up with my Ruby code. The first line simply includes the library I've written. The second line there will execute a command within the guest operating system. In this case it just adds a user, a VM user. I don't know if many of you have played with Ruby and C but they talk quite nicely and essentially you can write all your Ruby code in C if you want. Which is kind of useful. Especially if you want to play with something low level like memory or something like that. We'll move on to a few demos. These use some of the tools that I've developed some of the techniques that I've played about with in order to gain access to a VMware server and the virtual machines. I should probably explain the setup I've got. I've got a network with my laptop connected and it's from there that we're going to perform the attacks. I've got VMware server running and on that is a Windows 2003 box. Now we can assume that that 2003 box is completely firewalled off from the rest of the network. In fact maybe it's even sitting on a different network so gaining access we could use that as a proxy onto this new network. The first thing we want to do if we want to get onto the box is to obtain some credentials. The VMware command tool I mentioned earlier because that allows you to remotely administer and perform actions against servers one thing you've got to do is log in. By simply wrapping around that script we can perform a brute force because that's got to tell us if our credentials were good or bad. Here we've just brute-forced the user account JJ on the box <IP_ADDRESS> with our dictionary and you can see at the bottom we've succeeded with the password Defcon16. Now we've got some credentials we can take a bit more of the look at the box and see what else is there. Now VMware command can pull out a fair amount of info about a box and using the Ruby module I've written which essentially wraps around VMware commands we can pull out a whole load of information. At the top there you can see we've got a whole list of the virtual machines on the box. We can grab things like the power state and what users are logged on which is kind of useful if we can see who's logged on the box we can see more accounts that we can attack. At the bottom there we're reading the config file of this particular virtual machine it would be nice and easy to look around and read the config file of every machine. Now this works by pulling one parameter at a time from the config file and we've pulled out some useful stuff like in the MAC address. Now why is that useful? That's useful because if you're attacking a guest operating system it might well be on the network you're on and if you can find the MAC address you can tie that up to an IP address and then you can attack it from its IP address. Now I also mentioned that I've written some modules for the VIX API some Ruby modules which we can run nice and easily. I'll show you some of the potential of that now. Now what I've done is I've created a Metasploit payload which is a .exe file which we'll place onto the virtual machine and because we have the ability to copy files back and forth that's nice and easy to do. After that we'll execute it and we've got Metasploit sitting there listening waiting for this connection to come back. So we'll kick that off now. So first of all it's got to transfer the file across in this case it's called defconel.exe and you can see that's succeeded and it's executed the program. So now back in our Metasploit window we've got a session back. Now if we interact with that session we can do all sorts of things with the box. First of all let's take a look just to make sure everything's worked and now using Metasploit we've pretty much got full access to that box we've grabbed all the password hashes from the box as well we could have done pretty much anything we liked we can transfer files back and forth from it we can run whatever programs we want. So there's a fair amount of power if you're able to use the VIX API when you're testing. Well that was VMware Server we'll take a look at ESX. ESX architecture is slightly different and there's some different attack paths. Now ESX can be administered in many ways one of them is through a web interface which is what you can see there and again on the left we've got the inventory on the right we've got all the settings on the virtual machines and we can open up a console from there as well. Alternatively we can manage it using the virtual infrastructure client now this is a .NET application written by VMware and it talks SOAP to a web service which is running on the virtual machine and if you can I don't know if you can see but on the right there's also a virtual network ESX has the ability to create virtual networks as well as virtual machines so that's another thing that we can play about with an attack on an ESX box. Again if we want to attack ESX we're going to need to find it first because ESX doesn't sit on top of another operating system all of the ports we can see in the port scanner are relevant because they're ports on the ESX box. The most relevant ports they kind of depend on what you use it for but I'd say 4.4.3 is pretty important because most of the useful services run on that. One thing interesting about ESX is your ESX boxes are always assigned VMware MAC addresses no matter what manufacturer your network interfaces are it's always going to have a VMware MAC address. One thing I haven't mentioned is ESXI which is kind of similar to ESX it's a free version it was made free maybe a week or so ago it's pretty much I wouldn't say the same as but it's very similar to ESX it has fewer services running but again you'll be able to detect it on the network through looking at its MAC address and what services are running and map or fingerprint them quite nicely. So the services we have running slash SDK on the web server that's the soap interface which the VMware virtual infrastructure client talks to and some of the tools I'll show you in a bit slash UI is where the web interface is so you can again have a play with that slash mob is really useful if you're doing any development with the virtual infrastructure API it shows all of the objects on the ESX server and you can connect to and talk to them, query them pull out information, perform tasks so if you're doing any development I'm pretty sure you'll play about with that. VMware auth D still runs on port 902 but there's no VMware server D so you can't play about with it as much as you can on VMware server and there's also a console operating system which is running Red Hat and that's what you'll connect to if you connect through SSH interestingly root access is disabled by default for SSH but if you want to perform a lot of the admin on ESX chances are you're going to want to log in so I imagine most people would end up enabling root login for SSH right the virtual infrastructure API I mean it's got all the functionality you're ever going to need to play about with ESX now I've written some tools that talk to this API which I think are pretty useful when you're pen testing if you're going to use the tools VMware provide the majority of it's you're using a GUI which is a real pain if you want to perform repetitive tasks particularly if they're against the number of different servers so it's nice to be able to talk to that directly from a script or whatever things like checking security settings across all of your ESX boxes is something you'd probably want to script up at some point so yeah I've written some Ruby code which would talk to this web service and I think it would be fair to say it's not the nicest web service I've ever played with but it's pretty powerful so I'll show you a quick demo of what I've done now it wasn't very practical to ship my ESX server over here so I've had to record it but hopefully it will be clear I'll show you the output and talk through it afterwards as well the first thing we're going to do is connect to the box we can grab things like the version without authenticating but once we've authenticated we'll get back a session and we can perform loads of tasks, list the virtual machines find out a list of all the users even identify non-standard users or users with shell access we can then grab all the network settings we could play about with the network if we want firewall rule sets one thing that you can do with this that I don't think you can do with the tool provided by VMware is grab a list of all the patches that you might want to apply to that host so if you want to scan all your ESX boxes and find out which ones need patches this is quite useful I'll show you the output from that and we'll talk through that a little bit more because I don't imagine it was massively clear there I won't go through everything because a lot of it is self-explanatory so we've got a list of the virtual machines we can list all the sessions on the box in this case there's only one so it looks like we're the only person connecting because the users are users of the red hat costs they're pretty much your standard Linux users but we can find the non-standard ones in this case MWRITES but these are the users that are perhaps most interesting because they have shell access we can then grab all the network settings stuff like DNS servers and we can see here that the box has two physical network interfaces now here we can see that there's a couple of virtual switches set up we can see several different networks so it kind of indicates that they've got some quite good network segregation going on here we've even got separate VLANs on some of the switches now because your networks are completely virtual and your machines are completely virtual your ESX server knows which box is where so we can make use of this to ensure security the MAC addresses of your virtual machines aren't going to be changing regularly your IP addresses again aren't going to be changing regularly and your virtual switches know exactly where your virtual machines are and what they should be doing so you can disable forged transmissions MAC address changes actually if you enable these properties then any traffic that's forged will be dropped by the switch which adds another layer of security to your network additionally you probably don't want promiscuous mode enabled on your switches there's no need for your virtual machines to see traffic destined for the other virtual machines so we can flick that off now you can see in this instance that these settings aren't particularly secure for most of the interfaces that's just the default with the ESX we can grab the rule set for the firewall take a look, see what rules are allowed in and out by default there's a default deny inbound and outbound which is quite nice now if any of you use VMware server quite possibly use it as a secondary operating system maybe you run Linux as your main operating system or you want access to windows in which case it's quite nice and useful to be able to copy and paste back and forth between your VM and your main desktop when you run in a server probably you don't want the ability for people to copy and paste between the host and the guest operating systems and you can disable this functionality the last thing you want is to go copy in your root password and someone on one of your guest machines to paste it onto their desktop so you can set some settings that allow you to do that by default these aren't set in ESX so it's something you need to go out and do yourself and I mentioned the ability to check the patch levels here we can see a fair amount of info on the patches whether it requires your box to be rebooted afterwards what patches supersede it whether it needs you to turn your VMs off afterwards that kind of thing so there's a lot of information you can extract here and this kind of script is probably quite useful if you want to just check the overall security level of all your ESX boxes and whether you've got potential vulnerabilities there right now we're going to move on to a tool called DRADIS quite possibly a lot of you are sitting there thinking well there's quite a lot of scripts there that's a lot to play with it would be nice if they were put in a more tidy form now DRADIS allows us to do that we can pull them all together in DRADIS and make them nice and useful to us now DRADIS is a tool written by a colleague of mine it's free to download, it's on Sourceforge it's intended for information sharing and structuring of information during a pen test but it allows various different modules to be plugged into it and in this case I've plugged in my VMware modules so we can use all of their functionality now it works on a client server, architecture you run the server and anyone can connect to it add information, read the information so multiple pen testers can use it if they're on a pen test it's Ruby based and it's pretty extensible like I said I can add all my VMware modules to it nice and easily we can use it to put together a methodology for testing VMware networks if we like now it looks something like this on the left we've got a list of different objects or concepts on the right we can see the properties of each of these these concepts so on there I know it's probably a little bit small but we can see the settings for the firewall and for those of you that like the command line at the bottom there's a command line so we can run programs and operations from that as well there's also a notes tab so we can add notes specific to a host or to a test that we want to share with other testers as well now how does dryness work? like I said we've got concepts in this case we have the concepts of a VMware server of an ESX server even of a virtual switch or a network interface and we have various actions that we might want to perform such as creating a user rebooting a box checking the patch level that kind of thing and we build all of them into what's described as a universe so our universe describes all these different concepts and actions in this case we've got a VMware universe but it could be anything you could have a universe to describe your network in which case you might have web servers mail servers and you might have different actions such as checking the version or anything like that and you just plug it in as a module so let's take a quick look at a demo again because it wasn't possible to ship my ESX box over here we've had to video it for you now the first thing we want to do is boot the server up it's running web brick it's a Ruby server and then fire up dry disk like I said because it's client server architecture there could be multiple clients running and talking to the same server it looks like this we don't really need the command line at the bottom so we'll just move that down for now to give more space our concepts are on the left so in this case we'll create the concept of an ESX server now the properties of an ESX server in this case is just the version and IP address so we'll give it the IP address of our ESX server there's no reason you couldn't extend one of the modules to detect ESX servers on your network as well now we have properties for these concepts as well in this case we've got a version property so performing that action we can grab the version of the ESX server in order to log on to an ESX box we need some credentials and surprisingly there's a username and password so we'll enter them in so we've got a question if we didn't have credentials what if we didn't have them well let me just pause the demo for a sec if we don't have credentials then we're more limited in the actions we can perform there's a small amount of information we can grab from an ESX box most of the information you're going to need credentials assuming there's no vulnerability that lets you grab information from it first so for the purpose of this we're working with credentials but credentials can come at several different user levels so it might be worth running checks with different user levels to see whether your permissions are set up properly that kind of thing in this case yes it would because port 902 is open and running so the question was the tool I showed you for brute forcing authentication work and the answer is yes it would against this box because it's got port 902 open alternatively we could have brute forced the web service as well because it has a login function and we could attack it through that also we could brute force SSH so there's a variety of different options for trying to obtain credentials and then there's also the possibility that they share credentials across boxes so if we look at the case where we mounted the hard drive maybe some of the credentials we found then will be valid here as well ok so just jumping back here we've logged in and we've got back a session ID next we're going to take a quick look at the firewall see if there's any dodgy rules in there that might let us jump onto the box through other means so we'll populate the firewall ruleset settings and I mean we've seen these before from the script but it's a pretty default firewall ruleset and we can take a look at some of the authentication settings here we'll grab a list of sessions that are active on the server and we'll grab some of the non-default users as well because their accounts are normally quite interesting to attack and here we can see there's several sessions to the box so probably we're not the only person using it at this time and the next thing we're going to take a look at is the patch in and we'll find out what patches need applying on this box now in order to check the patch level you need a repository which contains the patches in this case our repository is on a web server and the web server structure it contains all the patches and the downloads it takes a moment or two to run because it's got to scan the web server for that information it will return at some point okay it's come back and we've got some details of the patch patches which we need applying which we can see there and again we've got information such as whether we need to reboot the box and that kind of thing and some recommendations you've seen some potential attack vectors if you're running VMware on your network you know what should you do well the first thing to note is nothing I've shown you today gives you access to the box without some weakness being exploited but perhaps there's vulnerabilities in VMware that we could exploit as well to get on there so it's important that we ensure the box is secure in the first place so how do we do that well VMware has written some really good documentation on securing well in particular ESX it's not a bad read so it's definitely worth having to look through if you've got ESX or server deployed you need to ensure that your updates are there I know it's it's one of those things that's always said but there's been a few advisories released I Defence and Core have put out some stuff recently and also because the cause is running Red Hat all of the Red Hat vulnerabilities also need patching as well so it's important to ensure that you keep on top of this and also Defence in depth steps you've taken to protect yourself VMware is always going to be a nice target for attackers and because it's probably running several of your servers it's important that this if there's one place on your network that you you go out of your way to protect then it really should be your VMware boxes and also don't forget things like VMware tools which are running on your guest machines they do leave the potential for attack like I said VMware is always going to be a juicy target for an attacker one of the key things that VMware bang on about and quite rightly so is to keep your management network separate from your corporate LAN the attacks we've seen today we're all focused against the management networks if they're not there then the attacks quite simply they just can't be performed and as I mentioned earlier disabled MAC address changes disable promiscuous mode ensure your boxes are secure as they possibly can be and your networks are secure as they can be it's unlikely that you're going to want to change MAC addresses regularly on your on your guest machines and also as I mentioned virtual machines if they're servers it's probably something you don't need if you've got a CD drive on your ASX server or your VMware server disable the guest machines from reading that last thing you want to do is put something sensitive in your CD drive which everyone connected to one of the guest machines can also see VMware's documentation states that only port 443 and port AC are needed for general operation of your server so if your deployment doesn't need access to any of the other ports then close them off in the firewall one thing worth noting is that guest operating systems do write their logs to the ASX server so it's important you make sure that they're rotated and tidied up pretty regularly the last thing you want is for your file system to fill up through a malicious user filling up your log files well I've still got plenty to play with I've found some pretty interesting stuff which I'll chat to VMware about sometime soon I publish it all when it's done but there's still a lot of technologies that VMware have produced that I've not played with I've not played with Vmotion for example it's something I'm definitely going to look at in the future well to conclude I mean the tools I've shown you they're all going to be made available on to the DEFCON CD because they weren't ready in time but they're available to download or will be very shortly from my website or www.mwrnfacesecurity.com Drardis is all I showed you you can download from sourceforge that's drardis.sourceforge.net so yeah go away have a play see what's useful to you if there's something that you think could be implemented drop me a mailer have a look into it there's no room to take questions but we've got a few moments if people want to fire anything at me we have a question the question was by default is there an account lockout on server on ESX not that I've come across I guess it depends on the settings you've got on your box one thing that I should have pointed out which I haven't is the auth daemon that runs on VMware server by default will run through inetd or xinetd if it runs through inetd then after about 250 will request to log in inetd will stop the service listening so you can cause a denial of service through doing that so make sure you run VMware auth daemon through inetd or if you're going to attack it will ensure it's running on xinetd before you do but back to the original question account lockout is down to whether you've said it I've not seen account lockout on either ESX or VMware server definitely not enabled by default now sorry by default server doesn't know that info is on the cd yeah right I'll move through to QA room if anyone else has got any more questions


Welcome to the OnFoTarget YouTube channel. This week I'll be introducing you to Dr. Herbie. She worked with the division of medical oncology department of medicine, Washington University School of Medicine, St. Louis, Missouri. Please enjoy. My name is Angie Herbie and I am a new assistant professor on faculty at Washington University in St. Louis associated with the Stightman Cancer Center and the Neurofibromatosis Clinic. I'm going to discuss a paper that I worked on during my postdoctoral years when I worked under the mentorship of Dr. David Gottman, who is head of the NF Center here. And the title of our work is Spatially and Temporally Controlled Postnatal P53 Knockdown. Cooperates with embryonic Schwann cell precursor NF1 gene loss to promote malignant peripheral nerve tumor formation. It's a mouthful. So I am a physician scientist and my clinical and research efforts are really aligned. So I treat sarcoma patients in the clinic and that is what I focus in my laboratory. And so one of our major goals is to gain a better understanding of the biology behind malignant peripheral nerve-shaped tumors. And one way that we can do that would be to study the genetics of these tumors. And the goal with that is to learn about what genes and pathways are important for the generation of these tumors and to try to identify different biomarkers that we can use to help in diagnosis and treatment. And so when we're talking about trying to identify new treatment options, it's really important to have some kind of preclinical model that we can use to assess treatment response before you would bring these therapies into the clinic to test in patients. And there are a number of mouse models for malignant peripheral nerve tumors that do exist. And I talk about some of these in the manuscript. But some of the major issues and the challenges with dealing with many of the models that exist are that they often require complicated crosses of mice. And so they take long periods of time for you to actually get tumors to study. Another issue is that you don't know where in the mouse body these tumors are going to show up, nor do you know exactly when they're going to show up. And so one of the things that I wanted to do when I was still in David's lab to have, you know, with me as I begin my new laboratory, were to have, to generate some kind of model where we would have control over when and where these tumors form. And so, you know, when looking in the literature, we decided to take advantage of the conditional knockout NF1 mouse that exists. And then, you know, add another common technique that people use, and that's the use of lentivirals, lentiviral system in order to, you know, knock down or overexpress other genes. And so we decided we'll just kind of start with the basics. We know, obviously, NF1 is important for MPNST pathogenesis. And so with the NF1 conditional knockout mouse, we know that that mouse will get the benign precursor lesions to MPNSTs, but they won't actually go on to form the cancers. So we wanted to see if we introduced some other genetic change that we know is important in MPNST biology, could we get these aggressive tumors to form. And so, you know, we know that P53 loss or P53 mutation is a major factor in a number of cancers, including MPNSTs. So about 30 to 50 percent of MPNSTs will have a mutation in P53. So we worked with some of our collaborators in Dr. Verma's lab and took one of their lentiviruses that would allow us to knock down P53. And then I perfected a surgical procedure in the lab where we could actually isolate the sciatic nerve from a mouse, from a NF1 conditional knockout mouse, and then use that lentivirus to knock down P53 in that specific nerve. And so by doing this, you know, we've generated a model where we do have control over where and when tumors can form. And, you know, as we discussed in the paper, we can get these tumors fairly quickly. So within about three months from the time that we introduced the lentivirus. And so this model is really a foundation that I can build on in my lab going forward. You know, we sort of showed proof of principle this works.  But as I said, you know, my lab is interested in understanding kind of all of the factors that that may be important in MPNST formation. And so future work in my lab is continuing in the line of genomic studies to try to identify new genes that are involved in MPNST pathogenesis. And then we can use this system to assess the importance of those genes that we find in our sequencing efforts. So for example, if we find a gene that is knocked down in a number of tumors, we can then engineer lentivirus to make a hairpin to this particular gene so that we can knock it down in our mouse model and see if, you know, that affects MPNST tumor formation. Or if we think that we find a gene that's overexpressed in our sequencing studies, and this may be something that is contributing to MPNST pathogenesis, we can generate a lentivirus that will lead to overexpression of that gene and then see how that affects the tumors that form in this mouse model. So, you know, I'm very hopeful that this will serve as a platform for us to identify and verify the importance of other genes in MPNST pathogenesis. And then eventually, we can even use this tool as a way to test drugs that may be beneficial in treating these tumors. By clicking the link below, you can learn more about the research discussed in the interview from the cover of Paper of Value 7, Issue 7. Thank you for watching.


I'm Mike and this is Mo, so I will be doing this is technically the sigauth deep dive. So I'll be covering a little bit of sigauth stuff. I'm going to give you guys a highlight reel of what we've been working on over the past years. So because I know it's been a while since we talked and then I'll hand it off to Mo who will begin the deep dive into pod security. So let's get started. So sigauth what do we do, what are we responsible for? Sigauth is primarily responsible for authentication, authorization to the Kubernetes API and various other security controls such as admission and authorization policy like RBAC and extensions therein. So one of the admissions that we're going to be talking about today is pod security admission. So what have we been doing for the past year or so? There's actually been a lot going on so maybe actually probably over a year ago we began discussing the defecation of pod security policy and discussing what it would mean to be a successor of pod security policy. And we knew that pod security policy had a lot of users in open source like we debated whether we can defer those users to look at out of tree strategies for doing the same thing like OPA. Ultimately we kind of landed on pod security which we will discuss in great depth that is going to be beta in the upcoming release of Kubernetes targeting beta in 123. The certificates API which had was long overdue for GA finally launched GA in 119. I think it had been around in beta since like 1.6 so it's like maybe three years overdue for going GA. Before the GA some notable changes were added such as a new signer name API so now the API can be divided between multiple consumers. After GA a duration hint was added so now you can sign certificates or you can request certificates for specific durations. The exec auth queue control plugin and extension also went GA in 1.22 I think which... There's either 1.21 or 1.22 I can't actually remember it now I think it's 1.22. And that paves the way for moving some of the final entry authentication plugins for clouds out of tree so that's kind of part of the whole club provider extraction effort. And we also have a proposal to extend support for those plugins to request signing and like mutual TLS protocols. And the token request API bound service count token volume and provisioning for bound service count tokens to replace like the legacy secret tokens all went GA. And I think the final GA was in 1.23 so that's I think a huge accomplishment. I think we had been working on that for a couple of years and it should benefit the entire ecosystem because those have significantly better security properties than the legacy tokens. There's some more work to do there. And finally the last highlight is we have a SIG subproject in called the secret CSI driver. There are actually implementations of CSI as the container storage interface. There are implementations of the secret CSI driver with backends for AWS Azure GCP and Vault. And that allows configuring volumes that project secrets and external secret storage providers. So I think the KEPF for GA and that just merged maybe this last week. Yeah, so we've been super busy. And with that I will hand it off to Mo. Cool. I'll make some quick comments on this stuff. So on the token request stuff, some of the stuff that's left is to stop generating the secrets, the back service accounts and really backpedal that functionality completely out of the API server or the controller manager. So there's KEPFs open for that. There's plenty of work there to be done if anyone wants to get involved. We're a very cautious bunch of folks. We don't want to break everyone's stuff like we understand that people run real stuff on Kubernetes now. So we're trying very hard not to break things, but we also need to move the ecosystem forward. So there is a balance there. And like Rita and Anish have been working on secret CSI driver for quite some time. So that is also a place one could get involved to try to push things forward. So the rest of the talk is mostly code walkthrough. So Tabitha and Tim had a talk earlier today at 2.30 that talks about the new pot security stuff from the perspective of an end user. This one is more focused as the perspective as a perspective contributor. If you care about how the code is implemented and maybe you want to get involved and help us get it from beta to GA and so forth. So everything in the code walkthrough is based on 123 alpha 3. So if you see something that's not what's in head of master right now, that's just that's probably why. But in particular, Jordan and Tim really set an incredibly high bar for the code, which is unlike basically anything that exists within tree, this thing has to run, be able to run standalone without like an API server can be run as a web hook, maybe be used in CI tooling.  So there's not like some large spaghetti thing that checks all the things. And the idea there is over time, you know, we'll evolve these things and add new checks or iterate on the existing check, but at a different version. So all of that stuff led to a pretty, pretty elaborate implementation for what sort of just sounds like a pretty simple thing. Like, you know, if this field is set on a pod say no, you're not allowed to do that because that's a privilege pot or whatever. So as most of this slide is just or sorry, most of this talk is just me going through the code editor, but I did have two slides. So as an example, this is from one of Jordan's examples on this stuff.  But you want to validate that they met some security requirements, right, and you just want to gate this. All right, so this is basically the skeleton of a tool that can run just completely without an API server, just and statically validate things, right. So the pot security stuff, unlike PSP is much more constrained, right, you basically say what level of the API you want and what version, right. So like baseline or restricted. So restricted is best, right. If you if your pod can work under that, that's what you want. And, you know, maybe, maybe you're on like version one dot 19 right now. And you're like, all right, I want to make sure that this stuff is going to run on 120. So I'm going to go ahead and try to validate against 120 and see like if I need to go talk to my developers and like, figure out some stuff before we actually move stuff forward. So like, you know, we pass those things and we'll go over like what the evaluator and the checks are like. But basically, if you're, if you're familiar with the Kubernetes code base, you're probably familiar with the builder pattern that we have. That's all this is doing is like, you know, passing in some files locally. And then it's just doing the visitor pattern on all those files. And so the actual visitor is basically like, all right, I was given something with a pod spec deployment, whatever, I'm going to extract that spec out and then I'm just going to evaluate it against the level and the version, whatever you passed me. And just check if it's allowed or not, right. So in roughly like 100 lines of code, you have like effectively like a production ready CI tool. And that's kind of the hope from this is that we want to enable people to build tooling off of this and, you know, offer value just outside of just pure Kubernetes admission. So the notes that I have kind of, basically I went through the code and tried to write notes on like interesting aspects that might not be completely obvious. So all the notes are on that fork of mine. So now I'm just going to kind of walk through some stuff and hopefully it will be helpful for folks. Can you all read that okay? We tried to make the text nice and big early on. So if you're familiar with Kubernetes admission, all of the stuff gets wired up in this API server package. So admission is ordered in the sense that it's a deny based system, right? So with a deny based system, the ordering of checks matters a lot because if you have an early check that denies the guarantees that the rest of the stack wouldn't run. So one of the things that, you know, pod security does is to make sure it runs before pod security policy. Because you can run pod security in an audit and warning mode. So it won't deny stuff. But what you could do with that is you could have your existing pod security policies, the old style, go ahead and put the new pod security stuff in an audit mode but in a very restricted mode. And just let it run and generate events as things are going on, right? And like you, the Kubernetes administrator can go check the audit log saying, I see that Moe is running this privilege pod. That doesn't meet the requirements now. I can go talk to Moe, go ahead and start getting this stuff rectified. But that's only possible if you run pod security in front of pod security policy. And I realize this is obnoxious naming, right? Because pod security admission or pod security policy, like it's very hard to understand sometimes what you're talking about. Also, don't be confused by this. This piece of code makes it sound like pod security is enabled by a default. It's not, it's feature-gated. So the code is there, but feature-gated off. This whole function is kind of a pain to read because it's like, what's off? But it's on, and then the intersection. So it's a little painful. Oh, man, it did not globally change the text size. I'm sorry, let's do, do, do, let's make it bigger. So I'm going to try, I'm trying to assume that folks don't know how the internals of CUBE work to some degree. So one of the sort of weird things within the Kubernetes code base is we have this concept of like an internal type or a hub type. So whenever we read your configurations or your objects, we read them as like pod v1 or whatever. There's an internal representation that's completely related, but it's meant to represent the schema across all versions. So obviously today, pod security doesn't necessarily have that. But you'll kind of notice some of this stuff. So like, in this, where it's doing the loading, if you don't provide it anything, it's going to be like, all right, I'm going to get the alpha configuration. I'm going to then default it. We'll look at what the defaults look like. Then I'm going to convert it into the internal version. Don't get too stressed about this, but this is like all over our code base. This happens all the time. But the defaults for pod security policy are kind of what you would expect, which is if you don't tell us, we just assume you mean privileged. And if you don't tell us a version, we just assume latest, which by the way, privileged means don't do anything. So in order to not break all your stuff, we do nothing by default. You have to tell us to do something. It is what it is. When you add something new that can break stuff, you can't just turn it on. You'll break people's stuff. So looking at the actual configuration, it's pretty straightforward, right? It's like, what version do you want to enforce that? What version do you want to audit that? And so, oh, I'm sorry, I will try to remember. The sort of interesting bit here is there is a hard-coded list of exemptions. So you can imagine that you have a pod runtime class that is, I don't know, running VMs under the hood and you're like, I don't need pod security. Like, I just have strict isolation. So you could tell us in this bit that like, yeah, if a pod asks for this, I don't know, Windows runtime class or something, just ignore it completely. Like, I have guaranteed out of band that this is safe. You could similarly have some user that's always allowed to run privileged pods or whatever. And then you're saying, I'm taking ownership of somehow gating access to these pods, right? Because if you can let, like, as a, for example, if you let arbitrary people exec into a running privileged pod, well, you have broken all security for your cluster. Let's walk through. So if we go back to the actual code, I always like to jump through the name of the plugin to actually get to where it's wired in. So it's pretty straightforward. It's like a, it runs on creating an update of a set of resources primarily. Let me find it. So it runs against basically namespaces and pods and anything that has a pod spec. But for the most part, the enforcing side is on pods, right? So the idea would be is that you don't want to break, like, a deployment controller with this. You just want to prevent the pods from being run. So because you can imagine you could have a mutating webhook that will coerce the pod into a correct shape when it's created, even if the deployment has something slightly different in it. So for the most part, it doesn't enforce on the embedded stuff. So we can kind of look at how some of this code works real quick. Let's see. Like the validation logic is, so as I just mentioned, like, so there's distinct logic for how namespaces are validated, pods are validated or pod controller, pod controller being like controllers that cause the generation of pods because they have an embedded pod spec somewhere within the schema like a deployment. So the most interesting one is pod because that's the one that actually does the real work, right? So it's like, all right, ignore sub-resources that don't matter and so forth. The reason for doing that is to hoist errors that you get as early as possible because it's terrible to create a deployment and have that fail three steps later asynchronously. Yeah. Yeah. But you can see like, you know, a pod evaluation, you know, is strictly enforced and which makes sense, right? Like at the end of the day, pod is what we have to prevent from running, right? Like everything else is a byproduct of all that. Let's see, let's see. I think some of the more interesting stuff is the whole registry. So with the old pod security stuff, right, you had this really expressive API and you would make individual pod security objects and you would try to say like, here's my policies. That level of expression is purposely omitted from this API because the other API is unmaintainable effectively. So what we have is basically this little evaluator thing which takes a series of checks. And so the idea is that this evaluator, you know, is given the input, it runs all the checks and says, is everything okay? Some of this code is like a little bit hard to read because it's trying to do like, well, you have a check at like version 1.12, but this is version 1.20. Oh, that's the like the newest check that's available. So it must also be the 1.20 check. It's kind of, it's a little hard to read at times. But for the most part, you don't have to worry too much about it. Jordan and Tim got it right, so you don't have to worry too much. The more interesting stuff is like the actual checks themselves. So there's like this global registry of checks and you can add to them. So what, oh, I'm sorry, I can read it, so I assume you can read it. I apologize. Yep, it does, it does work on that machine. So you know, what does a check happen? It's basically like a unique ID, what level does it run on like baseline and restricted and then the specific checks over time, right? So you could have a check, the same check change its meaning over time. This is one of the core requirements of the pod security stuff, which was, we can't just say like a check today is the valid over time because the pod spec changes, right? So if you had, if you add a new field somewhere within the pod spec that's privileged, like the equivalent of privilege, the existing privilege check needs to start accounting for that, but only add a newer version, right? We don't break you in place, right? No Kubernetes API is allowed to arbitrarily break in the middle. So to show you what that looks like, the privilege check is sort of the most canonical check, right? Which is like, don't let these fields be true. Like false is good or undefined is good, but true is bad, right? And we can see that this check has existed since the beginning of time effectively because these fields have existed since the beginning of time. So it's, you know, it's a very early check. And you can kind of see that it's like, all right, look at all the containers and by that I mean like all of them, like the innate containers, the actual containers, the ephemeral containers and maybe one day there'll be more containers than they'll also be in here. Look at all of them and make sure that nobody sets privileged equals true in there, right? And if they do, then fail with a nice error message, right? So that one's pretty easy and, you know, it's a pretty easy check. The run as non-root check, it's kind of long and kind of sprawling almost because it's got like levels of checks in it, so it kind of just keeps going for a bit. But the nice thing is that all of these things are completely distinct, right? So if the pod security standards change and we add a new check, none of the existing stuff has to change. We just add a new check to the rest of the thing. And to make it so that, you know, you can imagine a more expressive version of pod security that is completely implemented out of tree as a validating admission webhook. And let's say that someone wants to not run this stuff at all, they just want to run their whole thing. It would be really nice for them to be able to validate that the stuff that they have built conforms the same validation checks as the internal tree stuff. And so one of the ways we do that is for each of the checks, we have a test that generates a series of passing pods and generates a series of failing pods, right? So those checks are obviously run sort of in line in our unit tests and stuff, but they also generate, so if we look at this failure case and the zeroth index, they also generate YAML matching that. So all of this YAML is available, you know, in a very structured way, right? Like this is a baseline check at version 122 and it's a failing check for the privileged check, right? So if you were implementing equivalent code out of tree, you could run all of this YAML against your outer tree implementation and validate that it conforms exactly to the entry one, right? Obviously, you know, this is not a strict requirement for having pod security be a thing, it's just that Jordan and Tim were very careful to make it so that the ecosystem could build and mature on top of this stuff, so it adds pretty significant complexity to the work we had to do to make all this work. So I'm done with the code. Does anyone want to ask me something before I go back to the slides? I did have a question here from online and this is a few sentences, so I promise I'm getting there a little bit longer, though. What is the recommendation for organizations that plan to use something like Gatekeeper or Coverno to provide pod security pieces? Should the built-in pod security admission controller be disabled? Or is the recommendation to have them coexist with the built-in controller providing some basic level of protection and made more fine-grained by a third-party admission controller? So Mike, you might have a different opinion on me, just because I feel like this is an opinion and less of a thing that has a concrete answer. I would personally lean towards always running the built-in stuff in whatever mode is, you know, obviously if you can run everything in restricted latest, do that. That might be impractical, but, and then if you have further checks, add those checks as you're validating webhook or whatever you want, OPA or Coverno, whatever your favorite check is, because as you upgrade your Kubernetes cluster, this stuff will get upgraded by us. This stuff is tested by SigAuth. This stuff is maintained by SigAuth, right? And we care deeply about this implementation and we validate this one. So I would, I would sort of, that's the direction I would push people, but it's more of an opinion. It's not a strict guideline. Mike? Yeah. So one of the initial problems with PSP that was cited when we, you know, chose not to graduate from GA, to GA was that it was, users were incapable of turning it on in existing clusters without breaking their users.  So we would, like, we included kind of what we saw as the table stakes for constraining pods and, you know, we totally accept that our definitions aren't going to meet all use cases in the world. And I think in those cases, it makes sense to run, you know, OPA or Coverno. In that case, like, I would say you can use pod security admission for as far as it gets you and then use Coverno using both at the same time, really up to you. I would say probably it's not necessary to turn off pod security admission controller. And if you feel like you need to, then it's probably a problem with pod security admission controller and you should let us know why. Yeah, one of the core requirements of it was for it to coexist with other tools that are doing similar work. And PSP made that annoyingly hard. So we've tried hard on this one to not to have that, Evan. So as I understand it, right now, if I turn on the alpha flag in 122, all my namespaces by default are privileged or using privileged. Are there plans to either ship something so that when I create a namespace, I can set it down to a lower level or change the default in future versions of Kubernetes to steer users towards a more defended security posture? So I had this discussion with Jordan and Tim and David. They did not believe we could do that while maintaining the compatibility requirements of the Kubernetes API, which is unfortunate. At least basically what they said is this really comes down to the choice for your distribution and what security stance it has as this default posture. So as a, for example, I work for VMware in the Tanzu portfolio. As soon as this thing is beta, I'm going to go turn it on and I'm going to hit anyone with a hammer if they try to turn it off. But that's sort of the opinion of the distribution. At least the nice thing is it's very easy to go change the default and it's a very simple YAML file that just says if you have no labels, that means you're like latest restricted or something, right? Like you can really tighten it out very easily. It is a configuration that you pass to the API server. So it's like the rest of admission, the rest of built-in admission, it's a little unfortunate, but it's sort of, yeah, we just don't want to break people's stuff. If we were building Kubernetes all over again, I'm pretty sure we'd start from the beginning with this. Yeah, that was one of the core requirements. And if you are in an environment where you don't have access to that configuration file, it is also fairly easy to create an admission controller on namespace create and just set that default. All right, we have one other question and we'll look to the room if anybody else has any questions, too. This question is, with the built-in pod security admission implementation, is it possible for admins to add custom profiles or are the built-in privileged baseline and restricted profiles the only that will be available without a third-party admission controller? This one I can actually give an answer and, yes, baseline and restricted and privileged is all we plan to ever implement. However, the code is modular, so you can go ahead, fork it and use the same structure to deploy your own admission controller with your own profiles. Yeah, I don't even think you have to fork it, really, you just consume it. It is meant to be a library. You don't even have to fork it. So yeah, you could totally do that. But basically, we're trying very hard. One, we don't want to become a kingmaker here. We're not trying to rule your policy in all the little ways. But just also, this is what prevented PSP from going GAs because it was an ever-expanding API surface and trying to make it keep up with the growth of the pod spec over time just proved to be untenable.  And for the people who are willing to and have the need to go and define their own profiles, there are a lot of very good existing solutions that would allow them to do that, such as OPA gatekeeper or keyverna. So we felt like that was a problem that was already solved. Yeah. Yeah, at a really simple level, we want to make sure that in the future, on basically every Kubernetes distribution, sort of by default, create pod does not mean root on kubelet. If we can get to that stage, we have made an incredible set of progress into what the default is today in most environments. All right. Come over to you. I'm glad I asked for questions. I had a couple of questions about it. So when it was reading and trying to decide what to react on, it was looking for namespaces or things that had pod specs internally. So if you say create a deployment that violates some of the rules and it's turned on to reject it, it'll reject the deployment creation, or does it still allow the deployment to go through? It just rejects the pods the way pod security policy does now. So I might be misremembering, because what Mike said seemed to be mislined with what I had in my head. I thought it was we would reject the pod, but not the deployment. We would only audit and warn on the deployment. But I might be misremembering. I think that's right. So how is Warn mode triggered? So you have an annotation that sets whether it's enforced or worn? If I remember correctly, because it's under the pod controller path, it's always audited and worn for that piece, I think. The idea was that your deployment could be out of the valid spec, but you could have a mutating admission controller for pods that courses the pods into a valid spec. So the thing that gets created is allowed. So that was sort of the nuance that that... It's not great, right? That was my follow-up question, because there are... You couldn't mutate your pods in line and they can be eventually good. So rejecting the deploy outright would have been a bad idea. Yeah. So that's the use case we're trying to maintain is that we know that the pod itself is the thing that gets run. Everything else is implementation details, right? So that's where we really enforce. And the namespace stuff where it's really powerful is server-side dry run is a really cool feature. And what you can do now is you can do a server-side dry run that says, I would like to change the label on all of my namespace to restricted latest and just tell kubectl to do that. And what will happen is you will get back all the warning messages from the API server saying, hey, here's the like 17 pods across your entire cluster that do not meet this requirement. So... But you don't have to mutate anything to do that, right? So now you've got an immediate feedback on what you need to fix without causing any disruption to your cluster. And that's sort of like one of the cool things about this being label-based and just the maturity of the ecosystem now that didn't exist when PSP was originally written. Thank you. Awesome. We have time for about one more question, if anybody has one. Let's hop to the slides real quick, can't? All right. Yes. Cool. So we have some, we're always looking for people to join SIGOS and get involved in the community. So a couple good links for new contributors to check out these slides will be posted next to our talk in the schedule. So come check it out. We have some good first issues. We have a Slack channel and we meet every two weeks on Wednesday at 11 AM Pacific Standard Time. We'll have a lot of good conversations, a lot of ongoing initiatives to discuss there. And we welcome anyone and everyone to get involved. So yeah, thank you so much for attending today and hope you had a good keep gone. As a reminder, the PSP stuff is alpha. So if there's something wrong, please come tell us because we can fix it before we promote it to beta because it gets a whole lot harder because this is Kubernetes and we don't try to break people's stuff. Everyone likes to depend on every implementation detail of everything we built. But thank you all. Thanks everyone.


Income tax 2021-2022. Lifetime learning credits. Get ready to get refunds to the back. Stive in the income tax 2021-2022. Most of this information can be found in form 8863 instructions tax year 2021 IRS website irs.gov irs.gov. Income tax formula we're down at the bottom in the credit area noting that both credits and deductions are good but if you had a dollar credit versus a dollar deduction the credit would typically be better because you'd usually get the full dollars worth of the credit as opposed to the dollar deduction which would be a decrease to the taxable income resulting in the tax being applied to the taxable income. Also note that we have the two categories the credits we can think of those being the refundable credits and the non-refundable credits these are the non-refundable credits and the refundable credits the non-refundable credits don't take the tax liability below zero the refundable credits could result in in a refund if that were the case which isn't really a refund but more of like a benefit program in that instance. This is the form 8863 the educational credits the American opportunity and lifetime learning credits we typically think of them as kind of smushed together because you would typically be looking for first the American opportunity credit if you have educational expenses you're trying to get a tax benefit from because you get more of a benefit with it but if you can't get the American opportunity credit because it's more stringent in terms of the requirements then you'd be going for the lifetime learning credits. This is page two of the form 1040 in the non-refundable area line 20 this amount would flow into schedule 3 and then flow in here on line 20 this is the bottom of the 1040 where we have the refundable component on line 29 of the American opportunity credit from form 8863 line 8 so we're looking at the lifetime learning credit this is the second of the two credits this is the one that has less restrictiveness but has less benefits so you would first be going for the other one the American opportunity credit and if you couldn't get it then you'd say okay I'll default to the lifetime learning credit which is has more broad requirements and more likely that we could qualify for it so the lifetime learning credit equals 20% of the adjusted qualified education expenses defined later up to a maximum of 10,000 of adjusted qualified education expenses per return so you'd have to have 10,000 of them to max out the credit to take 20% would be 2,000 to get the maximum therefore the maximum lifetime learning credit you can claim on your return for the tax year is 2,000 regardless of the number of students who whom are you paid qualified education expenses so you might have like a bunch of people you know multiple people this time remember the last credit we calculated was per student whereas this time we're talking per tax return so if we had multiple students that are qualifying for the lifetime learning then we're capped out on a per tax return basis to that 2,000 so the amount of your credit for 2021 is gradually reduced otherwise known as the phase out if you're in AJI that's the modified adjusted gross income your income level is between 80,000 and 90,000 if you're not married in essence or 160,000 to 180,000 if you file a married filing joint return remember married filing separate causes problems with these kind of credit we talked about that earlier you cannot claim a credit if your MAGI is 90,000 if you're not married in essence or more 180,000 or more if married filing joint you cannot claim the lifetime learning credit for any student if you claim the American opportunity credit for the student you can't double dip you can't claim both credits for the same amount of the expenses so which one would you take if you could take them both you would take first the American opportunity credit because the benefit would be greater most of the time and if you can't then get that then you move over here to the lifetime learning credit qualified education expenses what are they generally qualified education expenses are amounts paid in 2021 for tuition and fees required for the student's enrollment or attendance at an eligible educational institution so obviously the tuition would be the most clear-cut kind of component that you would think of for the qualified educational expenses it doesn't matter what the whether the expenses were paid in cash by check by credit or debit card or with borrowed funds so you might say well what I mean if I borrowed the money is it the same it doesn't matter how you basically pay for it so once again it doesn't matter whether the expenses were paid for with cash a check a credit by credit or debit card or with the borrowed funds qualified education expenses continued for course related books supplies and equipment only certain expenses qualify American opportunity credit qualified education expenses include amounts paid for tuition that's the straightforward when fees that's pretty straightforward and course materials that's where it gets a little bit more sketchy what does course materials need which include which include books supplies and equipment needed for the course of study whether or not the materials are purchased from the educational institution as a condition of enrollment or attendance so a lot of times they say you know you need this materials you need like these books and whatnot but they're not like required you could go to the course without the book but you would be woefully unprepared if that were the case generally if you did that most of time so that's the American opportunity credit and now we're looking at the lifetime learning credit which is a bit more restrictive the lifetime learning credit qualified educational expenses include amounts paid for books supplies and equipment only if required to be paid to the institution as a condition of enrollment so once again difference between the American opportunity and lifetime learning American opportunity credit more expansive with regards to what qualifies for the expenses so the American opportunity credit again include amounts paid for tuition fees and course materials which include books supplies and equipment needed for a course of study whether or not the materials are purchased from the educational institution as a condition of enrollment or attendance whereas the lifetime learning credit qualified educational expenses include amounts paid for books supplies and equipment only if required to be paid to the institution as a condition of enrollment or attendance okay so the qualified education expenses include non-academic fees such as student activity fees athletic fees or other expenses unrelated to the academic course of instruction only if the fee must be paid to the institution as a condition of enrollment or attendance so that still seems fairly straightforward even though it's not tied in directly if it's a requirement to be paid you pay it and again those kind of payments you would expect then hopefully they would be reporting to you on on the documentation that the institution provides to you however fees for personal expenses described below are never qualified educational expenses so here's like the exceptions a note then when we looked at these educational expenses we're going to now be thinking okay they're going to give us the documentation which is at least going to give us the tuition and hopefully the tuition will be applied to the proper period we talked about the cutoff in the prior years so hopefully the institution will provide that and then we got to think about these other kind of things for qualified or these materials that we need to be adding and think well all of those items included in the documentation that the institution provides to us and if they are not do it could we include them in that instance and we might have differences in that case of course between the two types of credits that we're talking about so qualified education expenses don't include amounts paid for the following personal expenses this means room and board insurance medical expenses including student health fees transportation and other personal living or family expenses so no personal expenses any course or other education involving sports gains or hobbies or any non-credit course unless such course or other education is part of the students degree program or for the lifetime learning credit only helps the student to acquire or improve job skills so if it's a kind of a hobby thing it would be included but if it's going towards your your overall degree the credits then you would think it might then be included education expenses you may receive form 1098 T from the institution reporting payments received in 2021 box one however the amount in box one a form 1098 T may be different from the amount you paid or are treated as having paid so now you should be getting the form 1098 T and like we say that should have basically the tuition it should be included in there but as we see we've got these other things that may or may not be be added depending on the structure of the institution and how they make the payments and the requirements for it so you would think that you would need a 1098 T to tell you or as part of the requirement in most cases to be able to take the credits however the amount on the form 1098 T might not be the only amount that you that you would be picking up for the credits so to complete form 8863 use only the amounts you actually paid plus any amounts you're treated as having paid in 2021 reduce reduce as necessary as described under adjusted qualified education expenses later see chapter 2 and 3 of publication 970 for more information on form 1098 T so you can go to the publication 970 if you want to dive into that dip and more depth qualified education expenses paid on behalf of the student by someone other than the student such as a relative so some uncle the rich uncle paid for this the stuff they're treated as paid by the student so again it wouldn't really make sense like it doesn't really make sense if you had like a rich uncle that paid for the educational expenses of a student but then you don't get the benefit of taking the no one gets the benefit because the rich uncle doesn't claim the student as a dependent and the in the student if they're taking the deduction you would think they would get the benefit someone should get the benefit or otherwise the rich uncle would have to structure it as if they're gifting the money to the student and the student is paying for it right which is kind of a similar thing so any case qualified education expenses paid or treated as paid by a student who is claimed as a dependent on your tax return are treated as paid by you if you or the student takes a deduction for higher education expenses such as on schedule C form 1040 you cannot use those same expenses in your qualified education expenses when figuring your education credits so if you have a schedule C a business then you can't take the deduction on the schedule C and double dip in a sense basically getting tax favorable treatment by taking the same money elsewhere for a credit calculation caution any qualified expenses used to figure the education credit cannot be taken into account in determining the amount of distribution from a Coverdale ESA or qualified tuition program section 529 plan that is excluded from gross income so you can see publication 970 for that so if you're dealing with a Coverdale ESA then you can take a look at publication at 970 for for more detail on it so then we have the prepaid expenses what about these prepaid expenses again these are always coming into consideration qualified education expenses paid in 2021 for an academic period that begins in the first three months of 2022 can be used to figure an education credit for 2021 so again if it was the tuition then you would expect that the financial institution would kind of have that figured out because you will probably be paying for the first quarter or whatever they want to call it semester whatever of 2022 in December of 2021 so now the question is do you take that amount into consideration in 2021 or should it be applied to 2022 typically you would apply it to 2021 if paid in 2021 if it was for the actual tuition you would expect that that amount would be shown on on the documentation provided by the school hopefully but you might want to keep that cut off in mind for example if you pay 2000 in December 2021 for qualified tuition for the 2022 winter quarter that begins in January 2022 you can use that $2000 in figuring an education credit for 2021 only if you meet all the other requirements caution you cannot use any amount you paid in 2020 or 2022 to figure the qualified education expenses you use to you use to figure your 2021 credits so I think what they're trying to say there's obviously you can't use the same money that you paid in 2021 and 2022 so I couldn't say okay I paid in 2021 this amount for the first quarter of 2022 and I'm also going to take the that same money into consideration in 2022 right because you can only you can only take it you know one time on one tax year


The kind of challenges that developing countries face in generating revenue or collecting revenue from multinationals operating in their countries, we want to have a quick look at the BEPS process to see whether or not that process is positioned to address some of those concerns and finally I want to place it in an Irish context and see what if any role Ireland can play in ensuring that some of these things that would make a difference to developing countries can be an Ireland player role in that. So in 2011 a leaked audit report from the auditor's Grant Thornton highlighted that the Mopani mine which is a subsidiary of the Commodities giant Glencore was undervaluing their sale of copper out of Zambia to sister companies in Switzerland and exaggerating the costs of their labor costs in Zambia in an effort to minimize their tax bill in Zambia. To quote from the leaked audit report it said we believe that the Mopani cost structure cannot be trusted to represent the true natures of the costs of the Mopani mining operation and it requires more follow-up. Based on the two years for which the company was audited the Center for Trade and Policy and Development in Zambia estimate that Zambia lost out an 88 million euro in taxable revenue. The Zambian government themselves estimate that they lose on an annual basis two billion dollars every year to transfer pricing abuse in the main from the mining sector. This is in a country where life expectancy is 47 years. In 2013 the NGO Action Aid published a report entitled sweet nothings in which they detailed the elaborate tax avoidance scheme of ABF sugar UK food conglomerate which resulted in 17.7 million since 2007 to 2013 been lost to the Zambian exchequer. What's interesting from an Irish perspective is that part of that scheme involved the use of subsidiary company based in the IFSC which was charging for management and purchasing costs from their subsidiary company in Zambia on an average of 2.6 million years since 2007. It was taking advantage of the Zambia Ireland tax agreement which doesn't require withholding tax on purchasing and management fees coming out of Zambia. I should say that the subsidiary in the IFSC has zero employees. In 2014 Christian Aid and its partners in Sierra Leone produced a report entitled losing out and it highlights that the cost of tax expenditures incentives and exemptions granted to the multinational operating in Sierra Leone costs more than eight times the health budget and seven times the education budget. This is in a country where 50% of the population live below the poverty line. I give these examples by way of providing three distinct and different examples of the challenges that developing countries are facing. First is illegal it's an abuse of the arm's length principle and nobody should have any struck with that. The second is legal but it's an example how the system in its current format is being abused and milked by legal tax avoidance schemes. The third is an example of the pressure that resource rich capital poor developing countries are placed under to attract foreign direct investment into their countries while avoiding well trying to avoid a dangerous and damaging race to the bottom with their neighbors. There's lots of numbers bandied around around the extent and the volume of revenue lost to developing countries. They're all contested it's like trying to put a number on the drugs trade. What we do know though is and what the OECD agree with is that they are losing more money than they're receiving an aid on an annual basis. The question is can the OECD BEPS process address these issues and will it make it more easy or easier for the for developing countries to generate and collect revenue. The answer is probably not. There are real questions about the ability of the OECD to deliver reform equally for all countries. Fundamentally the OECD BEPS process is not set up to represent all countries equally. The OECD is as a membership of 34 of the wealthiest countries in the world and the BEPS process was designed for and by these 34 member countries plus the non OECD G20 countries and not with developing countries in mind. These sentiments are captured by Francophone finance ministers in a statement in Washington last year where essentially they say that the low income countries need an equal place at the decision making table. There have been plans for greater consultation from the OECD announced last month which are very welcome but fundamentally it's as much an acknowledgement that the process up until now has been fundamentally flawed at least from the perspective of developing countries. Inviting some developing countries into a process that is progressing I think it's agreed at a remarkable pace and to expect them to work to an action plan that has already been agreed will not get to the core of the problem of a lack of representivity inclusivity and participation. Christian Aid published a report recently highlighting these and other concerns and just to take two points from the action plan to highlight the fact that most of the issues that are relevance or of interest or value to developing countries have been de-prioritized and those that are of most interest and value to OECD countries are the ones that are getting most attention. Action point five to give an example commits the OECD to tackle harmful tax practices. This as illustrated by the Sierra Leone case has the potential has huge potential for developing countries if real action was taken on it was taken on it. However progress on this including progress on this has been blocked or has been very slow including blocked by some OECD members ensuring that little or no progress has been made on it. Action point 13 will require as we heard Pascal say this morning companies to report on a country by country basis this would provide the kind of information that people will need to be able to identify whether or not the economic presence of a company corresponds to the tax that they're paying. Again this would have been very useful in the Mopani mine case it would have held up a red flag very quickly that there's something irregular was going on. However the OECD doesn't propose that this will be placed in the public domain. In fact it looks increasingly likely that it will not be made available to developing country revenue authorities. We heard Pascal this morning say that these will be exchanged on a tax treaty basis. Well that's very unfortunate for developing countries who don't have tax treaties in the main with Switzerland or with Luxembourg or these countries where there is much less access to the information that they would require. Finally it's it's essentially a question of democracy. It has been said by by many including Pascal that the legitimacy of the OECD bets process lies in the fact that it represents 90% of the world economy. This may indeed provide it with an economic mandate but with over 100 countries not involved in the process it does not provide it with a democratic mandate. But I don't want to be too um unconstructive in my comments and I do have four quick things that I'd like to propose that could improve the situation of the BEPS process going forward. One more effective and real engagement with developing country governments and civil society. A focus two a focus on priority sectors for developing countries. The extractive sector, agriculture and a stronger focus on the specific needs and approaches that would help developing countries tackle transfer pricing abuse. The third G20 countries could provide a statement committing them to ending the beggar thy neighbor policies of tax practices which only result in a dangerous race to the bottom. A race to the bottom that Christine Lagarde has said just leaves everybody sitting on the bottom. And finally the process should take place within an intergovernmental body which is fully representative and fully inclusive. To conclude with to place this in an Irish context the Irish government is very much involved as one might expect in the BEPS process and there are two documents that should in part be guiding their engagement with the BEPS process. The first is the Ireland's international tax strategy from the Department of Finance of 2014 in which it makes a commitment to ensure that developing countries are able to raise their own revenue. The second document is that from One World One Future which is a government document which lays out Ireland's international development strategy in that there is a commitment to ensuring greater coherence across policy across government policy including in the area of tax and development. But it is precisely in the area of tax and development that some will see a contradiction between on the one hand a commitment to ensuring that the reforms within the international taxation system has been led by the OCD BEPS process ensuring that that benefits developing countries and on the other a commitment to what some will see as the harmful tax practices that form an essential and central part of Irish foreign direct investment policy. That Ireland has launched a spillover analysis of its tax work of its tax policy to see whether or not there is any negative impact on developing countries is extremely welcome and whatever the findings are when they emerge by the end of this year it would seem clear that there will remain attention between ensuring Ireland is able to thrive under whichever new international tax regime emerges and providing the same opportunities for others to develop and not condemning those countries to a continued reliance on aid. I'd like to conclude by thanking the Institute for inviting me to speak today and for giving civil society an opportunity to be present at this important event. Thank you.


Alright things are getting Confusing I don't know welcome back to the channel. I'm watching mob cycle episode 5 today called discord choices I think one episode in the first season started with discord, but mob is currently not in our reality I'm not really sure this almighty evil spirit has put him in sort of a new world without his powers to see how he'll act I don't know if it's just kind of like a dream slash nightmare Well, like I said in the last video I think he's gonna be very surprised by the way mob acts and how he's not like eotistical with his powers or anything So he'd be kind of the same kid We're gonna hop right into this one if you do the channel drop us up and hit that big boy bell and let's get started Asagiri Oh, wow, I think that's the shortest like intro thing as we've ever had is that the girl that they were supposed to be like all That like the very rich man brought them all there to exercise. There's black bars, too. This is so bizarre. It's like a movie Okay, so caga and friggin mob is still yeah, I'm still mistreated here This is an interesting concept though Yep, that makes sense people are cruel Okay, so mob can hear him saying this I think He already lives his life like he doesn't have powers the teacher hit him Oh, I thought Asagiri was gonna like take a liking to him. That's true though. He is surrounded by good people So this is where he doesn't have his brother Ritsu or anything. Oh, there's Ritsu This is a world where he's not even his brother or it doesn't care about him. Oh my god Okay, it's already become obvious to him That's true Hmm, that's an interesting perspective. I never really thought about it like that. Oh mob loves milk. Yeah It's something a lot of people do routinely. Oh my gosh, I Wonder why like maybe it's just like it's a true evil spirit that's trying to show mob how the real world is.  Oh my What happened what happened? Oh, that's right. We did learn about his life.  Oh Because of what he did. Oh It was his fault So he just doubled down Damn Even though they didn't even do anything inherently wrong at least most of them I'm guessing Everybody messes up and does bad things but he's trying to turn mob into like a new version of himself like the second coming of him Maybe because he recognizes how strong mob is Milk is bad for cats actually on back shouldn't give it to him too often God dude the way she looks at him Oh Is he freeing them? Oh, yeah, Reagan's is on his phone chilling dimples ready to give up on him base base Reagan Yeah, so body I hate that that dimples still has these sort of evil thoughts because I really do like him I can't tell how malicious they are though Could he hurt mom? No, he's not he's just sad it's gonna be overwhelming sadness Reborn as my sympathizer. Yeah, dude. He is trying to Oh, it's actually working.  It's her Yeah He's destroyed his mental Oh, no, we just let him hit him He wanted just like fast travel mob to this point Dimple can knock some sense into him. I like the differentiation between the the real world and not That's what the black bars are for he's trying to free him Yeah, I literally not throw this shot of dimples fist up literally knocking sense into him He's been here so long. Well in his head. Oh my god. Is Reagan calling him? Or is this like the Reagan here? Oh, wait, no, he probably wouldn't have a Reagan here. He would have nobody Oh my god, the OST is beautiful What is Mogami doing right now? Because he's been here so long. He's reminding him of everything the body improvement club Too long You're beloved there It was his beloved supami chan that knocked it into him. He's remembering everybody. Oh And buff mob was not something I ever expected Partner Oh His spirit is back feels good Yeah, well it'd be have like long-term implications Okay, so he what I figured he choose to use his powers for good not evil I think he pushed mob even further in a positive direction.  I'm still powerful as ever Oh Goodness, I'm getting mob like teru flashbacks when they first met She's nice. Is that part of Mogami like the spirit? Yeah, it is Yeah, but that's just how life goes man Can mob fix him It's all the torment built up inside of him. He like inherited it all Is that her? Trapped away I love when they do that like beam of light. Is that called like a solar flare? I think Every single like big fight in this show is just like fireworks for your eyes, man It's like throwing up all over me I love how dimple is here to witness all of this Two sides of the same coin. This is the the bright beam of light shine It's just like nuke after nuke after nuke one is light one is darkness two unstoppable forces 100 percent mob's positive emotions at 100% I think this is the first time he's gone 100% from positivity Oh, that's it Oh Yeah, positive 100 mob is very different than negative Wouldn't go out across the world He actually looks different bro. It's weird not just the hair of the face Dude with the beams all the like spirits are getting caught up in it He's still on the mission baby. That's my boy I feel like dimple has to gain some respect for him after this at least in terms of what I was saying earlier How he still has like evil intent Oh my gosh, maybe if they're all exercised and yeah, he'll like I guess kind of come back down to earth or maybe equal out a bit more That's when it's feeling like it's teased is his path leading to ruin and him having to make evil decisions Like his hand being forced It's still not enough to take him down.  It blows my mind There's like a billion things to look at at all times I feel like you can rewatch this 20 times and see something new every single time Like I don't even know what's happening, but I like it like dude Oh, oh The question mark person again. Was that because he collided with the evil spirit The question mark person was whenever you fought terror the first time and terror forces hand This is in mob or that's like the dark shadows is he's back Yeah, we were talking about different long times Oh, oh we got a spectator now Uh I didn't wouldn't trust that uh him having that spirit. Ah deal smiel. She's alive. She's awake. Hey another job well done from rakeins company Oh, she actually knows mob for being mob too. Yeah That's a good question Like mean She just said yes Kids man Oh here it is Is it like hit her all at once? Despite how mean she was to him Dude this show my god. Oh, she's telling her dad Or so you think he's kind of like batman in that way I My god psycho helmet. Here we go it grows evermore There's no way his his following is actually building They just said the guy the really rich guy just funded them. Oh my god It's at 500 000 yen No good ever comes out of drowning in welder power rakeins like i would never want to be that powerful And things are okay again dog this like over arching lies storyline about the psycho helmet religion And they're being followers was not something I expected I thought it was just like a throwaway gag at the end of an ever the beginning of the season I think it was I was like, oh that's funny. Some people are trying to find mob No, like they're actually funded now like they're gonna be a small army here shortly, but dude What an incredible episode the animation across the board and I like how mocha me and what he attempted to do with Mob backfired in the completely opposite direction like mob did learn a lesson out of it Just not the one he wanted him to he actually went further and towards the good path in terms of his powers Realizing that nobody's ever too far gone. So it makes me feel a lot better about everything considering an episode I think it was three where mob was feeling very conflicted about his power and how Like decisions he would maybe have to make in the future. I'm glad that he's feeling better about himself You can see more confidence exuding from him and everything he says and does it's nice Because it's been episode five of my mob cycle 100 watch who do drop a comment down below and what you thought the episode We thought my reaction and I will catch you in the next one. Peace base